Wednesday, November 17, 2010

Reporting bugs in PEM Editor

If you should be unfortunate enough to get a bug in PEM Editor, you'll see that the only information that the debugger provides is the annoying message "Source not available".

This occurs because PEM Editor is compiled without any debug information, in acknowledgement of those users who have PEM Editor and the debugger open at the same time.  (If PEM Editor is open when the debugger is open, performance slows to a crawl.)

However, you can cause PEM Editor to be re-compiled so that it includes debug information, so that you can report in much greater detail what the error is, where it occurs, and what the values of relevant variables are.  The steps are:
  1. Close PEM Editor and Document TreeView
  2. CD to the 'Source' sub-folder of the folder where PEM Editor is installed
  3. Execute the following line:
Then you can CD back to your original folder, re-open PEM Editor, and reproduce the error. 

EMail as much information about the error as possible to Jim Nelson.

If you need to re-compile PEM Editor so that debug information is excluded (because you use it with the debugger open), you can later repeat the above statements, omitting the single parameter to BuildPEMEditor.


  1. If i dock PEMEditor nest to Command, Property Sheet and Datasession (as a tab - pageframe style) and close the IDE, next time when i open IDE and start PEMEditor it restores itself docked as tab next to above windows.

    If i hide PEMEDitor (right-click on it's tab and choose hide), when i launch it from PEMEditor menu it restores itself as a tab, docked with above windows.

    Now, if i hide PEMEditor, then close the ide, when i reopen the ide and launch PEMEDitor, it appears undocked, retaining it's dimensions and somewhere close to the left side of the IDE (i keep my windows docked together as tabs on the right side of my IDE).

    Something happens after i hide it, when i close my IDE that PEMEditor "forgets" it's place in my setup :)

    Its only a minor annoyance, but maybe you'll remember about it when you fiddle with the code responsible.

    Thank you.

  2. Sorry about the minor annoyance. My hope has been to never fiddle with that code again. I actually had not done so in over two years.

    Hoping you can live with it as it is.

    BTW, I have found it works clearer if you dock PEMEditor yourself as part of the startup for the IDE, rather than relying on PEMEditor to put itself into the correct place.

  3. is there a way to dock it as a tab with the other in code? hopefully as the window is hidden ? or at least to hook into the Show() method to dock it when PEMEditor's main form is open ?!

    Right now, i'm launching it hidden (for the menu).
    What i want to do is either setup the docked option while is hidden so when it will be shown the form will start already docked, or,
    hook code into the Show/Launch routine so PEMEditor will position itself correctly when its launched (from PEMEditor menu).
    And i want to do that without changing the PEMEditor source (to avoid doing it again when i install a new release).

  4. Why are you hiding the PEMEditor form rather than closing it? You have said it works find if you close it.

  5. I guess i'm not as good a communicator, so this is an image that should explain it all :)

  6. You can dock PEM Editor programmatically like this:

    Dock name _opemeditor.outils.opemeditor position 4 window Command

    I suggest you execute this line as part of your startup for FoxPro, to insure it is docked as you like.

  7. Thank you, didn't know about that :)

    Now, since i'm running StartPEMEditor with .null., so PEMEditor will be launched only when i need it (via menu Launch PEMEeditor or Edit Property / Method) how do i run this command after PEMEditor is launched, how do i hook this into the event ?

    I'm hopping there is an internal mechanism, so i wouldn't have to create an object just to monitor _opemeditor.outils.opemeditor to see when it changes :)

  8. First, you don't need to start it with NULL so it will be launched when you need it later ... you can just use those same techniques to call it then, you don't have to have first started it with NULL.

    Second, you can't hook into the event, nor can you monitor the form to see if it needs to be docked.

    My suggestion, since your need is so specific, that you create your own hot key, using ON KEY LABEL, which calls StartPEMEditor to open the form and then docks it as well.

    Finally -- I have never quite grasped why it is that you want to hide PEM Editor in the first place, since it it already tab-docked. Why exactly are you doing that?

  9. Maybe is my machine, or my environment, but working with PEMEditor (the form) open at all times tends to slow things a little (especially when debugging). So i call it when i need to manage the PEMs of this class/form, then, later on (usually when i notice things gets slower, or realize that my debugger has all windows closed) i hide pemeditor - the form (which i believe is similar to closing it in this case).

    However, i've became obsessed (read dependent) to Dynamic Snippets (already created a few of them) and i like to have my environment set up for using them from the start, and the PEMEditor menu already loaded. (i'd like also to get into BeatifyX and the other tools later on).

    So, i launch PEMEditor (the system) with the form hidden so i have access to all the goodies but without all the monitoring / refreshing that the PEMEditor form is doing (checking current/selected property/method and changing relevant elements of its interface, hiding debugger windows - for speed, i know -, etc).

    Don't know if you really understand what i'm saying here, so don't worry about it, its just a minor annoyance - thought it was a minor glich to fix, but no biggie.

    Btw, it's not a bug, but when i'm adding a new method 'This_Acess', PEMEditor doesn't create the 'Lparameters' line for the created method.

  10. Yes, especially during debugging ... see the help file for a discussion of the unavoidable speed degradation when you have the debugger open when the PEM Editor form is open.

    The curious thing here is that if you merely HIDE PEMEditor, the timer is still running, so it is still impacting performance. I would expect the perceived difference in effect whether hidden or unhidden to be truly minimal.

    So what you really need, I believe, is the following:

    (1) When you first call StartPEMEditor, do so with an empty argument, which shows the form.

    (2) Then dock it, as indicated in my earlier message.

    (3) Then close it ... _oPEMEditor.oUtils.oPEMEditor.Release()

    Then, when you need (but don't have) is a way to close it when needed, instead of hiding it. You can't do this yet. I am trying to see a way to give this to you.

    If you close it, re-opening it will cause it to re-dock properly. You can test this be closing it as above. One way to do this is to use a hot key to do it for you.

    No doubt there will be more on this ... I await your response.

    Switching topics ..

    As for Dymamic Snippets, I am very interested in what you are doing. I hope to give more complete documentation on it in a blog within the next few weeks. Can you let me know more w about what you are doing?

    Finally -- if you are creating a method called This_Access, PEM Editor doesn't know about the parameters. It only knows about parameters when you check off the access or assign checkboxes when saving a property.

    Cheers from sunny Southern California

  11. I will email you the scripts i have created, they aren't state of the art but they gets the job done.

    As for the This_Access method i know it gets only one param, the PEM that is accessed (but maybe i'm wrong)

  12. When copy/paste pems from a class to another, it forgets to set the private/hidden setting to the pems copied in the destination class.

  13. Thanks, I'll try to include a fix for handling visibility when doing copy/paste in the next Alpha release

  14. When i change the visibility of a native PEM, PEMEditor sets the visibility to my setting, however, when i try to change it back PEMEditor throws an error "Member *PEM* is a class member" (try it with BackStyle property, but its not limited to it).

    My debugger shows that the error is in RemoveMember() on the line with 'Removeproperty(.oTopOfForm, lcCleanName)', below '.removeMemberData(lcCleanName)'

    The method is called from EditPropertyMethods(), the line with '.removeMember(lcOrigName, .T.)', above 'Endif Not .oMember.IsNewMember ...'

    Probably preventing the change of visibility for a native member would be a solution, but i'd really like to have this possibility available.

    I got in this situation (a couple of times) by trying to add a hidden *property*_Assign / *property*_Access method. It seemed intuitive to me - check the Assign and select the visibility :)

    The thing is that i never learn that checking the Assign and selecting a visibility option will in fact apply the visibility to the property and will add a public Assign method.

    Maybe it should be considered that this be the default behavior of PEMEditor if it seems more natural to other devs. also

  15. Eduard --

    (1) The bug you reported has been corrected in the version released today.

    (2) You can change the visibility of native and inherited properties and methods from public to protected or hidden, but you cannot change them back; VFP just does not provide tools to do that. If you need to, choose the option from the context menu of the combobox which reads something like 'VFP Default "Edit Property/Method...' and follow the directions.

    (3) The checkboxes for Assign and Access simply provide a direct way to create the appropriate methods when working on a property. The visibility checkbox applies to the property, not the Assign or Access methods.


  16. Thank you. My suggestion was that if a user checks an the Assign/Access checkbox and changes the visibility from the combo in a "edit session" (does both things than saves) probably its intention is more than likely to create a protected/hidden Access/Assign method for selected property, thus PEMEditor could create the Access/Assign with the selected visibility - in this case only.
    Since every developer has it's own quirks maybe a checkbox in the properties dialog that toggles this on/off would be acceptable .. that is, if i'm not the only one that would like this implemented :)

  17. Eduard --

    Your suggestion seems a little over-complicated to me, both to explain and implement.

    What if the rule was that any new Access / Assign methods be created with the same visibility as the property they are associated with?

  18. First, i want to apologize, i should have started this conversation in the 'Suggest New Features' page, as it is not a bug.

    Usually i create Assign/Access methods containing code that encapsulates some kind of behavior related to the property, behavior that i don't want to be messed with (or i want it hidden).

    If you think that the idea is not worth implementing that is ok, but if you didn't understand my proposal i will try to explain better. Hope you'll bear with me for a little while.

    So, from what i see, PEMEditor goes to edit mode as soon as i change something and saves the changes when the user clicks the 'save' button.

    I propose, that when PEMEditor sees that there is a visibility change and a checkbox (value=.T.) change for Assign or Access to apply the visibility change to the newly to be created Access/Assign method.

    If the is only one of these (not both - visibility and create access/assign) PEMEditor should behave as it does now.

    In other words, if it detects a batch of two actions (create assign/access and change visibility) it should create the assign/method then apply the visibility to the newly created method, if it detects only the visibility change should apply the visibility change to the property, if it detects only the change in the assign/access checkbox it should only create the access/assign method.

    Also, if it's not too much, and with regard to other developers who like it as it is now, this behavior could be toggled on/off with a checkbox in the settings form.

    A different variant would be to (this could be complicated) allow the possibility of overriding the default action for the 'save' button via plugin, that way i could create a plugin that will perform these specific actions when this specific situation occurs and i wouldn't have to worry about doing it again for the next version.

    Or.. not, after all its your project, your choices, and you've already done more that i would have expected this project to become. Personally i'm truly grateful and usually awed with every 'new functionality/tool' version :)

  19. Eduard --

    First, no need to apologize about which blog post you added this comment to.

    I fully understand your suggestion, but I do have a question:

    Under what conditions would the suggestion I made earlier today not be sufficient for your needs? I would think that the most natural way to assign visibility to the Assign and Access methods, when they are created, would be to match the visibility of the property they are assigned to.

    What I am really asking here is why you want to enforce that the user change the visibility AND create the methods at the same time. As a user, I would likely find that sort of mystical -- sometimes when I create the methods, they get the same visibility, sometimes not. In fact, if implemented as you suggest, my guess is that some would report its behavior as being a bug.

    BTW, I never use visibility and use the Access / Assign methods infrequently, so I am making guesses here about their behaviors. I am not, however, making guesses about what I think would be quirky UI behavior.

  20. For example I create a ControlSource property for a specific container-based class. However since I created the ControlSource property I have to make it work as much as the native one, but i also want the handling methods to be hidden (that is, provide the illusion of a native ControlSource property) - this is a common scenario for me - anyways, I don't need to override the corresponding Assign method in subclasses or on the forms and don't like the clutter in the Property Sheet. This is an example. In this case the ControlSource property is public but the corresponding Assign method is hidden.

    I don't know about other devs habits but what code i place in Access/Assign is not to be messed with and its code that once it works i want to forget about it and just enjoy the benefits.

    I don't want to enforce. Its ok how PEMEditor works right now, my proposal is to add a new variant, that when the user marks the checkbox to create an Assign/Access method and chooses a visibility, then saves (the "batch") then PEMEditor might realize that the user's intention is to create the Access/Assign method with the selected visibility.

    Applying the property's visibility to the handling methods (if not otherwise chosen) should be default i believe. How strange would be to see a public Assign handler with no public property.. however it sounds interesting :)

  21. I have never wanted to change the Visibility of a PEM at the inherited or VFP Native levels. Yes since recent I wanted to create them all Hidden unless I specifically want the PEM to be otherwise but this will be at the level of the PEM being created.

    IMO Access / Assign should be Protected by default. I should only manipulate the Property itself, the logic of access or assign should not be accessible. I mean no other class (nor itself) should manually call access / assign and should rely on the automation provided by VFP. Protected, just because logic might need overriding down the inheritance.


  22. Eduard --

    Thank you for the description of what you want to achieve and why. I think that is quite clear.

    What is not clear is why the suggestion I have made, to always assign the visibility to Access / Assign methods (created by checkboxes) to be the same as the property they relate to, is not satisfactory to you.

    My belief is that the application of visibility in general, and in particular to Access and Assign methods in particular, is relatively rare. I say this because there have been so few questions about the handling of visibility within PEM Editor over the years, and also because those few whom I have asked about visibility have indicated that they simply don't use it.

    So for me, what this boils down to, when there is already a mechanism in place to allow you to set the visibility for Access and Assign methods (albeit rather roundabout), what would be a an easy to understand and easy to implement mechanism to assign visibility to those methods?

    Surely the description 'The Access and Assign methods are created with the same visibility as the property they related to' is easy to understand (and, I think, easy to infer). It is also very easy to implement.

    If implemented, what difficulties would it cause you?


  23. Bhavbhuti --

    Your request is related to, but somewhat different than, Eduard's.

    Currently, in the Preferences form, there is an option for entering the default visibility for new PEMs.

    Would it work for you if there were a new option that said 'Visibility for new Access/Assign', where the choices were Public, Protected, Hidden, and 'Same as that of property'?


  24. Jim --

    No difficulties, it should be by default in my opinion, the 'create method and assign visibility' combo is just a shortcut i would have loved, but, is just a shortcut.

    From my experience with PEMEditor i found out that i do 'the combo' when i desire to achieve that result - and without giving it much thought - i guess it seems more intuitive to me.
    Whenever i want to just create the method or change the property's visibility i do only that and not both actions - so i thought that it would not interfere with other user's habits. But i might be wrong.

    Actually, that is how i stumbled upon the bug with resting a native property's visibility - i selected BackStyle, checked the Assign, changed visibility to hidden then clicked 'save'. When i've realized that i've hidden the BackStyle property i tried to set it back to public and - the bug. Maybe a warning would be a good idea (if its not already implemented as i haven't checked with last two or three versions).

    I believe that this would be more versatile than the solution you proposed in answer to Bhavbhuti, but that would still be ok.

  25. Eduard --

    I think there are two different issues here:

    (1) I think it a great idea to warn the user if they attempt to change the visibility from public to protected or hidden for native or inherited properties, since it is not easy to change back. Similarly, if they try to change it back to public, they should be notified of the steps that need to be followed, since PEM Editor cannot do this.

    (2) As for assigning visibility for the Assign and Access methods, I think it is not possible to determine what all people will consider to be intuitive, so I will use the rule stated earlier which will allow those who care about it to learn how to use it.



  26. Not exactly a bug, but when i RClick -> PEMEditor in ide's Property Sheet, PEMEditor opens/activates, it selects the PEM in grid, but not in the editing controls ->

  27. Yeah, sort of a half-bug.

    Am curious -- you clearly have the property sheet open and use PEM Editor. What do you still use the property sheet for?

  28. Its faster an clutter free - use it when i'm editing and auditing. When i get into class / form build mode i use EEMEditor extensively.
    The fact that it interferes with debugging is another reason :)

    I love PEMEditor, but it doesn't have the speed of the native property sheet :)

    This is one of the reasons why i'd like to have as many PEMEditor features/tools accessible while PEMEditor (the form) is not visible/loaded. The PEMEditor menu was an excellent idea.

  29. With last version, i get an error "Variable 'CTYPE' not found" in ActivateForm() on the line ".BindControls = .T." below "* Turn on data binding now that we have something for the control sources."

    It's not consistent, from what i've experienced, it doesn't throw the error when i have no form designer or class designer open.

    Should have i done some cleanup (temp tables, etc) before installing the latest alpha ?!

  30. Eduard --

    Thanks for the note about how you use PEM Editor and the Property Sheet.

    Be aware that the current Alpha version of PEM Editor is compiled such that it includes debug information, which means that it is very slow when the debugger is open. This can be alleviating it as follows (and this will not be necessary when it gets to Beta and then to Production):

    Go to the Source folder, and execute BuildPEMEditor(). This re-compiles without the debugger information. If you have problems doing so, exit FoxPro and start a session when PEM Editor has never been loaded.

  31. I know, however if no major refactoring has been done since the last beta (vfpx) it should move the same - won't hurt to give it a try thou, and the grid still has it's quirks (it's a grid) not as stable (stable as in 'earth under my feet' stable) as the native property sheet. The combo especially is slower but that can't be much helped :)
    For me is good as a 'load when need' for creating/editing pems. With much of the general functionality loaded in the PEMEditor menu and the global key hooks i'm as happy with it as i can be :)

    Note, when i'm talking about 'PEMEditor' i'm referring to the 'PEMeditor' form, the one where we create/modify/search PEMs and not the whole app (menu, hooks, docview, etc)

    Btw, at the rate it is growing in options and functionality i believe you'll have to change the name at some time in the future. It outgrown a log time ago the simple task of PEM-editing. It has become a whole system of productivity enhancement with complex functions. Tho, most of them are related to pems and pem editing so i don't know ..

  32. Eduard --

    Well, there WAS major refactoring since the Beta release in VFPx, but that should not affect the speed at all. However the Beta did not include debugging info, the current Alpha releases do, so the current Alphas should run a lot faster when the debugger is open if they are re-compiled.

    Glad to hear that you are happy as can be! Nice feedback. There are indeed lots of features in this tool, and my simple hope is that people are able to find and use the features that fit their needs.

    Finally, as to a name change -- that has been suggested, but it does have some name recognition now. I am not sure I want to lose that.


  33. Hi,

    I am using the Sep 3 release of PemEditor 7.

    Double-click a property with character value and bring up the ZOOM editor dialog, the [Font...] button at the bottom won't work. Its always says: "Property EDTZOOM is not found"

    FYI, this release of PemEditor has corrupted one of my VCX file. It inserted objects of invalid class at random position in the VCX. (Invalid class name is somehow taken from some class property name). I am lucky I save that VCX using HackCX pro.

    Unfortunately, I can't remember nor can I repeat the steps to trigger that error. I just want to leave a note here for such incident has happened to me and may be it is a good reminder to everyone that they need to backup VCX file more often.

  34. Thank you for reporting the bug in the zoom editor dialog when you tried choosing a font. That bug will be corrected in the next release of PEM Editor (as yet unscheduled).

    As for the problem in your VCX, I can safely assure you that that problem was not caused by PEM Editor. PEM Editor does NOT write to a VCX, ever.

    Instead, it only uses native FoxPro methods and functions to create and update properties and methods. It is only when you save the class you were working on that the VCX is written to, and FoxPro does that, not PEM Editor.