Property Editor Issues

Topics: General, Bug Information, Attention VFPX Admins
Developer
Mar 30, 2008 at 7:45 PM
Edited Mar 30, 2008 at 11:06 PM
1) BUG: Open/create a form, got to Form - Edit property/method to open the editor window, now in the grid click in the "Controls" property of the form, you get a "Program Error" message box: "Controls is not an object"

2) BUG: In the same property editor window, when you click on a property in the grid, then click on a method, then on a property again, the Favorites checkbox adn the Assign Method checkbox overlap each other.

3) BUG: In the property editor, select a custom method or property, clear the Name textbox, now click on another property/method in the grid, an empty property/method is added at the top of the list. Also, do the same thing but after clearing the name type a space or any other invalid character in the Name textbox, you get a warning wait window that the character is invalid, and then click in another property/method, an empty property/method is added at the top of the list, click on it, and you get a Syntax Error message box.

4)FEATURE REQUEST: Related to BUG (2) how about the Favorites checkbox stays always in the same place instead of moving to the left when changing from a property of a method? It would be easier if that checkbox was always in the same space, and also, don't hide the Access and Assign checkboxes for a method, just disable them.

5)BUG/FEATURE REQUEST: When I rightclick in a custom property/method in the VFP properties window and select Edit Property/Method, the clicked property/method is not selected in the grid of the property editor window that pops up. Is that a BUG or a FEATURE? And the title of the window is like : "Edit Property 00004oax02s9.tmp" Why do we have to see that tmp value there? Could the title just be "Edit Property/Method".

6)FEATURE REQUEST: Could we have a column for Favorites like we have for Access and Assign in the grid? And by just clicking in the Favorites column checkbox the method/property is added/removed from the Favorites Tab.

7)BUG: The Member type radio checks stay enabled for native properties/methods.

8)BUG?: Changes are lost without warning when clicking in another preperty/method in the grid and the Apply button was not clicked.

9)FEATURE REQUEST: Can we have one layout shared between properties and methods, and enable/disable the controls instead of hiding/showing controls, so the editboxes and everything is always on the same place and not moving/resizing around?

10)FEATURE REQUEST: An edit context menu for the editboxes with the usual stuff: Copy/Cut/Paste/etc.

Who is/are the author(s) of this project?

Carlos Alloatti
Developer
Mar 31, 2008 at 12:32 AM
11)FEATURE REQUEST:How about text in different colors in the property editor grid? Custom PEMS in another color, just like the native Properties window, that way we can easily find the custom properties and methods.
Mar 31, 2008 at 7:00 AM
The author it's Marcia Akins, you know her right Carlos?, by the way keep on the good work with your classes.
Coordinator
Apr 2, 2008 at 12:16 AM
Hi Carlos.

1. This happens for both Controls and Objects, and likely other properties such as PageFrame.Pages. The error is in edtDefault.Refresh: it uses EVALUATE() to get the current value of the property. That code needs a TRY around it.

2. I'm not seeing that.

3. Definitely a bug.

4. I think that's a good suggestion.

5. I'm not seeing that either. The property selected in the Properties window is automatically selected in the Edit Property/Method dialog and the dialog caption is the name of the form or class.

6. Another good suggestion.

7. This is just a visual thing, and it's actually in VFP bug, IMO: disabling a container like OptionGroup prevents its contained controls from receiving focus but doesn't disable them so they don't appear disabled. That being said, this is an easy fix.

8. I'm not seeing that either.

9. I don't see why not.

10. Another good suggestion.

11. I agree -- I'd like to see that too.

Doug
Developer
Apr 4, 2008 at 8:21 AM
Edited Apr 4, 2008 at 8:36 AM
Hi Doug, thank you for your comments, now you have me worried, about what you can't reproduce.

a) I downloaded from https://www.codeplex.com/Release/ProjectReleases.aspx?ProjectName=VFPX&ReleaseId=8575

b) Unzipped file, copied the 3 app files to Microsoft Visual Foxpro 9 folder in program files.

c) Cliked on the 3 files one by one, 2 of them registered succesfully, the other I understand is for creating property scripts.

Is that the proper procedure for installation? Is there anything I have to check/delete/repair? Is there any other version to try?

2) Overlaping checkboxes, here is a picture: http://img370.imageshack.us/img370/1973/propertyeditor1pp5.png

5) I don't see the tmp name now, let me explin again the other problem: I right-click in a custom property named "ctlVisible" in the VFP "Properties" window, and select the "Edit Property/Method..." menu item in the context menu that pops up.

That opens up the property editor form, and in the grid, the "current record" is the "Anchor" property. I would expect that the "ctlVisible" property would be the "current record", but no, I have to scroll all the way down to select the "ctlVisible" row in the grid to edit it. As a matter of fact, the property editor window always opens with the grid positioned at the "first record".

You are not seeing this? You get the property that you right clicked on as the "current record" in the grid? Then what is wrong in my setup?

7) I understand now.

8) You are not? This is what I do: In the property editor window, I select a property/method by clicking on it in the grid, then I type a description in the description editbox, now click in another property/method, type another description. Do the same for another one, for a total of 3.

Now you entered descriptions for 3 properties/methods, click again on each of them, you can see the text you entered in the description editbox.

Now click in the grid in yet another property/method, not any of the 3 you entered a description for, and then click the Close button. Now reopen the property editor, and check if the 3 descriptions you entered are there. What I see is that they are lost. Now, if I click the Close button while having one of those properties selected, the comments are saved for that property, lost for the other 2.

It seems that changing the active record in the grid saves the changes temporarily, but they are not written back to the form/class when you close the editor, unless you click the "Apply" button for each one. This may be a feature or a bug, depending on how you see it, but maybe a "save changes" dialog would be better when changing the active row in the grid, or just an implicit save.

Of course, I'am posting all this here to contribute back, not just for being a nitpicker. Is Marcia the only one responsible for this fine piece of code? Is she willing/going to follow up on this? EDIT: I found the DH initials in the code, I guess that's you.

PD:

12) FEATURE REQUEST: Autocomplete for the Name textbox, I forgot that one because I added that myself, and it has been a great timesaver when editing all the properties of my classes. I never cared about proper case before, since _memberdata was a nightmare to maintain.

13) A bigger font while we are at it, for us blind people! (I think 9 point is better for the more common higher resolutions used today)

What a great timesaver this is for me! Thank you very much for sharing it!

Carlos
Apr 6, 2008 at 4:54 AM
Edited Apr 6, 2008 at 6:03 AM
It would be really great if we had these features available.

One new feature request:

Automatically send a text to the clipboard that contains the modified PEMS, their defualt values and Comments.
This is extremely useful when we need to document a class or form.

We could just paste the clipboard's content, and all the documentation would be ready.

This information is stored in the VCX table, in the "Reserved3" field.
At this moment, I'm opening my VCX as table, and retrieving all this info directly from there.
Coordinator
Apr 8, 2008 at 7:55 PM
Hi Carlos.

Just to be sure we're working with the same version and there's nothing on my system that makes them work, I set up a Virtual PC, installed VFP 9, downloaded and installed the projects file from http://www.codeplex.com/Release/ProjectReleases.aspx?ProjectName=VFPX&ReleaseId=8575, unzipped in a folder (not the VFP program folder), started VFP, and ran NewPropertyDialog.APP and NewEditPropertyDialog.APP to register them.

2. Still not seeing it.

5. I selected a custom property called cCaption in the Properties window, right-clicked and chose Edit Property/Method. The cCaption property is the selected one in the grid in the Edit Property dialog. So, I'm not seeing what you see.

8. I see what you mean now. Yes, I can reproduce that.

12. Good suggestion.

13. I agree. Microsoft used 8 point for all the VFP dialogs but I think 9 point would be better.

Doug
Developer
Apr 10, 2008 at 1:51 PM
Hi Doug,

thank you for testing this. I upgraded my computer this week, so I have now a clean install of Windows XP and VFP9. I copied NewPropertyDialog.APP and NewEditPropertyDialog.APP to the VFP9 install folder, opened VFP and ran them to register them:

2. Overlapping checkboxes is gone now.

5. Still not getting the property clicked on as the active record in the grid, so I did some experiments also, using a virtual machine too. I found out that if you install both apps in the VFP folder, the currently selected property is NOT selected in the edit property dialog. If you install both apps in another folder (as you mention you did) the currently selected property IS selected in the edit property dialog. Really weird bug, who knows what is going on here.

Testing this, I found another problem:

You copy NewPropertyDialog.APP and NewEditPropertyDialog.APP to the VFP folder, run them to register them.
Now you move NewPropertyDialog.APP and NewEditPropertyDialog.APP to a new folder, run them again to get them registered, messagebox says they got registered, but in fact nothing changed, records in foxcode.dbf still point to the original folder location, so dialogs don't work anymore.

When the apps register in foxcode.dbf, it seems they do a seek to find their own records in foxcode.dbf. If those records are found, no attempt is made to update them, even if you moved the apps location.

In my testing, I had to replace foxcode.dbf with a clean copy after I moved the apps location. I think the apps should re-register when the app location has changed. Or maybe a command line argument could be added to unregister the apps?

I would do all this myself and post the code, but I hardly manage to understand how all this works, never touched foxcode.dbf.

Carlos
Coordinator
Apr 10, 2008 at 3:39 PM
Hi Carlos.

Thanks for the update. Interesting about running in the VFP folder as opposed to another folder. I'll have to look into that. Also, I'll look at the registration process.

Doug
Developer
Apr 11, 2008 at 4:37 AM
Doug:

New findings, and as they say... the plot gets thicker..

I have done more testing, and I think I have narrowed the problem: The one factor affecting the way the dialogs behave is whether or not there are spaces in the path where both apps are located.

I tested by uninstalling VFP from my computer, and deleting all the VFP folders and registry entries that I could find. Then I reinstalled VFP9 and SP2.

I made a backup of the "Microsoft Visual Foxpro 9" folder in program files and of the "Visual Foxpro 9" folder in documents and settings...\Microsoft.

Then I unzipped the NewEditPropertyDialog.zip file into a folder "c:\PropertyDialog". I run VFP, did "Program-Do" and registered both apps.

Now I open a class, point to a property already in the favorites tab in the properties window, right-click on it, and I get a menu with the following menu items:

Reset to Default
Zoom
Edit Property/Method
Add to Favorites (Incorrectly enabled, since the property is already in the favorites TAB)
MemberData Editor...

If I click on the "Edit Property/Method" menu item, the Edit property window comes up, and the correct right-clicked property is the current record in the grid.

Now I close VFP, delete "Microsoft Visual Foxpro 9" and "Visual Foxpro 9" folders, copy them over from my backup, and rename the property editor folder to "c:\Property Dialog" (Notice the space).

I run VFP, and "Program-Do" both apps, open the same class, right-click on the same property, and I get a menu with this menu items:

Reset to Default
Zoom...
Expression Builder...
Edit Property/Method...
Add to Favorites... (Correctly disabled, since the property is already in the favorites TAB)
------------------- (A separator line)
Help...

Notice the difference between the two menus, some items are missing in the first menu, some items have "..." in the second menu.

If I click on the "Edit Property/Method" menu item, the Edit property window comes up, and the "Anchor" property is the current record in the grid (Anchor seems to be the first record), no matter which property I right clicked on.

Also, to add to the weirdness, only in the "no spaces in path" case, if the VFP "Properties" window is on my second monitor, when I right-click on a property/method, the menu pops up in the first monitor!

The menu vertical coordinate is correct, but it is positioned horizontally flush left with the VFP _Screen left border, in the primary monitor.

I had not noticed this before, since I mostly had the "path with spaces" case in my setup.

What I have not being able to determine, if there is a difference if you change the order in which you register both apps. I tried to register them always in the same order.

Some other things:

Why do we have native properties listed in the PEMs grid, but not native events and methods?

Why the title of the form is "Edit Method - ClassName (VcxName)" or "Edit Property - ClassName (VcxName)", depending if I right clicked on a property or a method, and does not change as I select properties or methods in the grid? maybe the title should be always "Edit Property/Method - ClassName (VcxName)".

I hope you find all this useful.

Carlos
Coordinator
Apr 11, 2008 at 11:05 PM
Hi Carlos.

Yes, that's very useful. When I get a chance, I'll check it out.

I can't answer "why" questions; you'll have to ask the author Marcia Akins. I can see that the form caption should be changed, though.

Doug
Developer
Apr 16, 2008 at 9:12 AM
Doug:

No problem, the "why" was just a rethorical question.

Carlos
Developer
May 11, 2008 at 4:21 AM
Edited May 11, 2008 at 11:31 AM
Carlos and Doug,

I've found how we can access the old PEM editor, having the new facilities for the Automatic Memberdata:

Select the "Class" menu,
Then "Class Info", click the "Members" tab, and finally "Modify".

I'm using this to be able to set many properties modifications together. This way, I don't need to click on "Apply" everytime, and it is more reliable, because I've faced some cases when I clicked on the "Apply" button and the property did not change.

Cesar
Developer
May 13, 2008 at 2:39 PM
Hi Doug,

Unfortunately, I prefer to disable the latest modification in the PEM editor.
Yesterday I passed through a big problem, because it broke one of my classes.

Suddenly, I got an error, and all my custom methods / properties became properties.
Some code was lost, and could be retrieved only by opening the VCX as table.

For me, it's not reliable to be used in production yet.


Can you point me how can I disable that form and use the original instead ?

The original Property / Method that you first published works as desired. What I want is to disable only the last modification that changed the PEMs screen.

Is it possible ?

If I install the previous version will I face any problems ?

Thanks in advance,

Cesar
Coordinator
May 17, 2008 at 8:00 PM
VfpImaging,

Can you duplicate the error? If not, can you provide the steps that you think might have caused the error. Sounds like something that needs to be addressed if it is a problem.
Coordinator
May 23, 2008 at 9:48 PM
Hi Cesar.

As Craig mentioned, can you post some steps to reproduce the problem? I use the replacement Edit Property/Method dialog almost daily and haven't run into any problems with it.

If you want to disable it, USE (_FOXCODE), BROWSE, find the record with ABBREV = "MENUCONTEXT", and delete it.

Doug
Developer
May 26, 2008 at 1:13 AM
Hi DOug and Craig,

Sorry for the late answer. I've been trying to reproduce the error, breaking the class again, but it did not happen again. I remember that when it happened, I selected the optionbutton in the lower right corner of the form, changing a property from Method to Property or vice versa. As the property already has a value stored in it, an error occurred. After that, all methods and properties showed in the grid as "Properties".

I'm sorry to say that I had some other difficulties with it, and faced most of the issues related by Carlos above.

Thanks for the tip showing how to disable it.

I hope Marcia will find some time and motivation to improve it.
The concept is really great, and I'd love to have those issues fixed.
Jul 2, 2008 at 3:36 AM
 This is with regard to the new Method/Property windows application available from the VFPX site.

I have a problem with it. When you click on any property, a menu is supposed to pop up.

Unless the property window is UNDOCKED, the Right click menu for the properties window mostly displays the popup menu in the wrong place as documented below.

Rt. click on the properties caption and make sure "docked" is ticked.

1. If the properties window is docked at the extreme bottom of the vfp screen, the popup appears at the extreme top of the vfp screen, near the middle of the bottommost toolbar.

2. If the properties window is docked at the top, then the popup menu appears at the extreme bottom of the properties window.

3. If it is undocked, the popup menu appears in the right place(docked is still ticked)

4. If the properties window is TAB docked with other windows, and the complete tabdocked set of windows is NOT docked, the popup menu appears in the right place.

5. If the properties window is TAB docked with other windows, and the complete tabdocked set of windows is docked at the top, the popup menu appears at the bottom of the tabdocked set.

6. If the properties window is TAB docked with other windows, and the complete tabdocked set of windows is docked at the bottom, the popup menu appears at the extreme top of the vfp screen, near the middle of the bottommost toolbar.

7. In a Dual Scree Monitor situation where each monitor displays a different window where the VFP screen is maximised in monitor 1 and the complete tabdocked set of windows is dragged to monitor 2, the popup appears at the extreme left of the VFP screen in Monitor1.

8. If The VFP screen is not maximised but is made to stretch across both monitors, the popup appears correctly.

This appears to be a serious bug in the positioning of the menu and is causing me great frustration, since I mostly develop as in situation 7 and have the popup appear at the extreme Left of the VFP screen is causing much mileage with having to move the mouse from left to right.
Coordinator
Jul 2, 2008 at 6:29 PM

Hi Bernard.

Just to be precise, this is in the replacement Edit Property/Method dialog, not the New Property/Method dialog. The code that does menu positioning is in the record in (_FOXCODE) that has ABBREV set to 24460. It looks like the code calculating the location of the Properties window needs to be tweaked. I don't know how much time Marcia has to look at this right now, so you might want to look at the code in the DATA memo and see what needs to be changed and post the results here. I'll pass this on to Marcia in case she does have time, though.

Doug

Jul 4, 2008 at 8:48 AM
Heya,

Have recently installed new version of New Property/Method dialog and I am having 2 minor issues (i.e. not urgent):

1) Not sure what might be causing this but now when I use the "Reset To Default" right-click menu option I have to do it twice. Basically click menu item, menu re-draws itself and then I have to click it again to get it to reset

2) More a behaviour issue I suppose but when I "Edit Property/Method" make a change to a property or method, like rename, them move off  the selected item I see the name changed in the dialog immediately, great. However if I go to another item, say I am renaming multiple items, without hitting the Apply for each one, I loose all my changes when exiting the dialog. IMHO, I should be prompted if I have not "applied" all changes or by default save all the changes.

Again, great work guys (and gals)!!!!

Toodles,
Steve Dingle
Coordinator
Jul 8, 2008 at 12:58 PM

Hi Steve,

Long time no hear, and good to see you here! Hope all is well.

I had the same problem with the shortcut menu on the property sheet, but no one else reported it. I might have been running one of the many betas Marcia sent me to test, or more likely I tweaked the script code and broke something.

To fix it I made sure I downloaded the latest release, jumped into the FoxCode.DBF file and deleted the MenuHit records related to the new property/method dialog and editor.

Abbrev = "MENUHIT", "NEW PROPERTY...", "NEW METHOD...", "MENUCONTEXT", "24460", "EDIT PROPERTY/METHOD..."

I PACKed the FoxCode table too for good measure. Then reran both APP files so the dialogs were reregistered. Everything is working as expected.

Rick

Jul 8, 2008 at 1:31 PM
Heya Rick,

Doing ok here, hope all is well with you. Your suggestions did the trick, thanks!
Jul 9, 2008 at 9:21 AM
Heya Rick,

Alas its back :-( Very strange, worked fine yesterday, today I'm getting the double hit again. Was being lazy, suppose its time to get into the code itself and see if I can find a solution

Toodles,
Steve