Hi Jim,I suggest you add a feature to read the structure from a table, and present the fields so that the generated text can easily be modified into useful code, for instance for a SQL Select statement. I see for me a solution where there are two steps.1. Select a table, either from the MRU list, or via a getfile() call.2. A prompt with three options: a. Prefix with the name of the table b. No prefix c. Prompt for prefix.The result in the editor then should look something like this: prefix.Field1,; prefix.Field2,; prefix.Field3,; prefix.Field4,; prefix.Field5,; prefix.Field6An even cooler solution would be if step 2 also showed a Mover to select which fields should be included.Personally I would LOVE to have this feature added.Tore Bleken
Tore --That's a wonderful suggestion. I, too, would love to have this feature. I am adding it right now to the 'Under Consideration' page.Would you be interested at all in working on the UI for this feature? If so, it could be implemented a lot quicker. (Yes, of course, I'd have to supply you with details)JRN
I have a couple of suggestions:- A feature to create a block of code with thisform.object.Controlsource = "cursor.field" (i use late binding to controlsource in a specific method) with options to exclude controls, step inside containers, specific cursor name. (i have a prg that generates this if it helps). Or to create a block of code that sets any property to any schema.- I also propose a tool that allows a "bird's view" of all (or selected) objects certain property (like controlsource, Anchor, Left/Right, TooltipText, Name, Caption, etc). The user could choose the property from a combo and in a grid will be displayed the object's name (with containership path to 'thisform') and the value of selected property. Should allow for modification (in-grid preferably). How easy would it be to verify and correct if all objects have proper controlsource/name/caption/anchor from just one screen. - A feature to save a schema of properties values. That could be pasted on another object (with creation of properties if desired). I know, this kind of duplicates the functionality of copy/paste pems from the combo's right-click menu.more to come :)
Three different suggestions! Great!(1) I am not sure what you are getting at with this. Perhaps your suggested PRG would help me see what you are proposing.(2) If I understand you correctly, the "bird's view" you are requesting is already available in version 6.10. Try using the binoculars; the release page in VFPx (link to the right) describes how it all works. Yes, the ability to verify correct the same property for many objects simultaneously.Right now, you must double-click to edit a property, but a most likely enhancement will allow you to edit in-grid.(3) Saving a schema of property values? Since you reference the copy/paste options in the context menu, you must have something else in mind. How do you want to save property values? And how will you restore them?JRN
(1) The prg that i'm talking about is a script that creates a block of code which assigns the countrolsource of all objects in the selected / active form (open for editing). I thought about making a UI which allows me to check in/out objects to be included/excluded from this block of code, also the property to assign and the default value (or either a schema to interpret). From here i got to (2) .. (2) You're right (of course you are) i thought that was some fancy search system (which i planned to learn about some time) but the result is similar to were i was headed: a single form/grid listing the objects and the propertys values. btw, i searched for ".caption" and i get an error ("array dimensions are invalid" - in grdObjects.SetupRow) when i scroll down through the results (with mouse wheel).(3) Nevermind about that, i thought about saving/applying a certain "style" (top/width/color/font/custom properties) to classes/objects (even between different baseclassed objects). I thought about a method to replace the inheritance of visual elements or at least a system more dynamic/adaptive :)If i'll get my thoughts in order and it proves to be a viable option then i'll write to you again about it :)I'll send you an email with my "DevTools" menu. The code is created / refactored / improved upon at different periods in time and it may seem childish in some areas and better in others. I apologize for that. Although it might seem trivial to you (the code / implementation) some of the items might give you an idea for features to PEM Editor. Hope it helps.
edyshor:(1) I can't see where you are going with creating your block of code, other than to say this: If you can imagine having editor window open, and being able to write code to create a block of text to insert into that editor window -- you will be able to do it with PMDs.(2) Believe it not, I am VERY interested in any and all bug reports. If are able to reproduce this problem, I ask you to do the following:- close PEM Editor- CD to the folder where PEM Editor is installed- CD Source- BuildPEMEditor(.T.)This will rebuild the APP so that there is debugging info.Then, when you reproduce the error, you could relate what line the error is occurring on so that the error can be fixed.(3) + (4) I look forward to your thoughts on the issues expressed on these items, even though I can't quite see what you are attempting to achieve.Actually, the hope is that PMDs that are created that are of general purpose will be made available on the VFPxRepository site. Sounds like you are likely to have some submissions.
This is curious: - DynFontBold() -calls-> This.SetupRow (loColumn, nObjNumber) && nObjNumber=17 - SetupRow() receives loColumn, tnObjNumber && tnObjNumber = 0 - the error is trigered on 6th line [loObject = Thisform.aSelectedObjects (tnObjNumber)] where tnObjNumber = 0 It doesn't happen every time, just ocasionaly. I've searched first for "caption" w/o "." it returned no objects found, and then i've searched for ".caption" and the objects where shown in the grid. Next, i scroll from MouseWheel and click on different cells. After some time i get the "Array dimensions are invalid" error.Hope it helps.
Well, I don't understand how or why that is happening, but you gave me enough information so that I can correct for tnObjNumber = 0ThanksJRN
Hi,I would like to suggest when PemEditor passes parameter to getnewmethodheader.prg (the plug-in), the first parameter will be className.MethodName instead of the method name alone?I have big problem with this small issue, my problem is when the flow of codes is in getnewmethodheader.prg, code editor has not yet run (with the object being opened) and so, I can't even use WONTOP() to get the missing "className".tslim
RE: GetNewMethodHeader:I will provide a mechanism for doing this in the next release. Either, as suggested, passing in the full name into the PRG as a parameter (although I don't like this, since it will change how this will work for others), or by providing an alternative mechanism for determining the class name.Part of the next release (which won't be available til early next year) will be that some of the internals of PEM Editor will be published in such a way that you will be able to access them directly.
Hi,Not really bugs...Whenever I tick the [Access] or [Assign] checkbox for a property, I understand that I have to press the [Save] button so that PemEditor will create the corresponding _Assign or _Access for me, but:1. When the new _Access or _Assign method is created, PemEditor does not call the GetNewMethodHeader.prg to also insert a header. Isn't it suppose to do that?2. I notice that beside creating the _Access or _Assign method, PemEditor also save the property as Non-Default, which mean I would see that property if I tick the "Non-Default only" checkbox. But I actually has not made any change to the default value of that property.
Hi:(1) Well, I suppose it really is supposed to add that to new _Access and _Assign methods. You are right -- nobody had ever asked for that before!(2) PEMEditor creates new properties by using all four parameters of AddProperty, which includes the value. This makes it non-default. This is an issue that was discussed a long time ago, and we decided to leave this behavior as is.
Hi,I would like to make some suggestions to the PemEditor Filter:1. Add an option to auto-clear the filter when another class or form is opened up in PemEditor. I have countless incidents where I scratch my head for minutes why certain property or method is missing... only later realize that I have set filter in PemEditor... :) Anyway, I like filter. 2.Make it possible for me to set a hotkey to clear filter.3.Could I ask for filter MRU? (am I too greedy?)
(1) Your suggestion about auto-clearing the filter when a new form is opened makes sense. I will add that to the list.(2) There IS a hot key to clear the filter, if the focus is on PEM Editor -- Alt-T. As part of opening up PEM Editor, I will see about enabling some features like this for you accessible via hot keys.(3) Filter MRU ? What do you mean exactly?
Filter MRU... :)I mean a picklist for say the last 10 filter expression I have set before.
I guess I can consider having a list of the last 10 filter expressions set, but see it as a really low priority item.
Would it be possible to add two options 'Change to Hidden/Change to Protected' in the property sheet context menu?It will allow for fast setting of visibility options to PEMs for someone who plays allot with them.Would be wonderful a 'Reset visibility' too, but i believe you said the only way a native/inherited pem to reset it's visibility would be full reset (value / code also). Is that correct?
Eduard --I'm not very interested in adding new items to the Property Sheet -- my intent is to provide a tool which is a replacement for the property sheet, even though I realize most people use both. Thus, adding features to the context menu doesn't really appeal.I would consider it, though, if it were fairly easy to implement. Turns out that it's not. Furthermore, since it only take four clicks to change visibility in PEM Editor, I see no outstanding advantage to doing so.Jim
Would it be easier to implement multi-select in pemedtor's grid and applying a bunch of options to the selected items as a group - change visibility to multiple pems at the same time for example ?!I'm happy using it both as most of my developing time is spent writing code in forms's and class's methods, switching back and forth for reference, at times having multiple classes or forms for editing, writing in multiple methods, checking properties and correcting on the go. PEMEditor is still slower for this type of usage, at least for me. I know it can't be helped much as its written in vfp - meaning the ide and debugger will always watch 'over the shoulder' - and i'm ok with that, what i'm trying to say is that i don't think pemeditor will ever 'fully' replace the native property sheet. It could do all that the property sheet does but still .. And in any case, pemeditor its not anymore defined solely by the form. What about Dynamic Snippets, BeautifyX, etc. tools that are there to be used without having the form open? And if the native property sheet won't get the copy/paste pems upgrade (what are the chances of that happening) the form is the only way to go :)Using both of them is natural to me. I wouldn't want to see the group of options to add/modify pems when i'm editing methods or setting values to properties. And the space occupied by them would be wasted (considering my task). The property sheet is ok for that. When i need to get into create/modify mode i 'launch pem editor' from the menu, do my stuff close/hide it (or, as of late, i simply leave it there, it goes away by itself in time - you've seen that part of my ide).
(1) Easier to implement Multi-Select? Not really -- and, besides, my interest is in developing other new features (like all the IDEx stuff) that are not available anywhere else.(2) Yup, it's slower that Property Sheet. For me, though, that's more than offset by the ease in navigation of objects and filtering of PEMs. Beyond that, I take advantage of the property editors and event handlers (particularly for resizing). Couldn't live without that either.I only use the Property Sheet to navigate into pages of a pageframe (something PEME has trouble with)(3) It also takes some screen space; it can be docked, of course, which helps some. I use two monitors, so I have lots of space to work with.Jim
i need two monitors :)i'm stuck with a 15.4" notebook :(
Wonderful tool, I love it.But one little suggestion.1. Would it be possible to implement in the document tree that it does not load every time I click on the drop down, cause I have forms which need about 30 seconds to show the tree.2. Not to expand all nodes in the document tree on startup.Best regardsJochen
Jochen --Document TreeView works much better if you have it as a separate form. You can do so either them the PEM Editor menu in the VFP system menu, or set it up in the preferences form. When you use it as a separate form, right-click in the white space, and you'll see an option about expanding all nodes.I am most amazed, by the way, that you have a form (or forms) that take so long to load. Can you tell me more about them?
Hai Jim,thanks for the really quick reply!1. Yes you are right it is a little bit faster in a seperate window, but I'll try to use it as a complete replacement for the property window, and it is docked on the right side of the ide. It is not so comfortable to have another window to use, even on my big monitor.2. No, not expand all. When I open the document tree first time all is expanded, I'm looking for the opposite of this, first start, nothing is expanded. So it is easier for me to move thru the object tree.3. My main form is a really big one, I think. It is a crm solution with hundreds of objects in it (round about 520). It has multiple pageframes in pageframes, etc. and uses the Outlooknavbar and some other nice additions combined together.4. I have looked at your source of Pemeditor 7 Beta and changed 2 things to solve the above mentioned points.editpropertieform->loadnode() If lbAnyMethods loNode.Expanded = .F. Endifgridcontrols.oobjecttree.cbocombo->dropdown()changed:lbReDraw = .T. && not (Thisform.lTreeViewShowMethods and This.Parent.Parent.lTreeviewCurrent)back to:lbReDraw = not (Thisform.lTreeViewShowMethods and This.Parent.Parent.lTreeviewCurrent)Now it is really fast again, but I think next update all is gone again.Best regardsJochen
Jochen --Since you don't have room on for both the PEM Editor and Document TreeView forms separately, I suggest that you tab-dock them. This will not take up any more space on your screen, but will allow you to use the separate window for Document TreeView. It also appears that you only are interested in using the document treeview as a navigation tool to objects. If this is correct, you can uncheck the 'Methods' checkbox; this will greatly reduce the time necessary to create the treeview, and also have the effect that it will only be expanded to show the currently selected object.I am also kind of mystified why your form should take so long to load -- I'd like to pursue this with you separately, if possible. Please contact me at JimRNelson@GMail.Com. Anything that takes that long could well afford some attempts at optimization.
Thanks Jim, that was the solution!Best regardsJochen