Sunday, July 24, 2011

Some ramblings on the FoxPro Class Browser

Some time ago, I delved into the Class Browser, to extract and modify the code that allows you to drag the icon at the top left of the form and drop an instance of a class elsewhere.  (This was done more in the way of a challenge than anything else.).  I was able to do so; see Open Files

Then this last week, there was a UT thread that had to do with adding objects to columns, and I learned that there were other good suggestions on how to do this, but not using the Class Browser.  (I learned that you can do so by first selecting an object already in the column, and then dragging onto that column creates a sibling. -- but this seems quite cumbersome, and difficult to remember.)

Since I already had visited that same code and plunked it into PEM Editor, I took a look at it and found that there was an easy fix to allow dropping objects into a grid column.  Very easy in fact -- modifying exactly one line of code to include 'column' in the same list as 'container' and 'page'.

And this was enough to whet my appetite.

I have now made a few modifications to my own copy of the Class Browser:
  1. Problem with not being able to drag/drop objects into a column has been resolved.
  2. You can now drag an object onto the PEM Editor form, and the object will be added as a child or sibling of the currently selected object as displayed in the PEM Editor form.  This means you can select a column in a grid, or possibly a container that is obscured by other objects, and be able to safely drag/drop.  (You can drop it anywhere on the PEM Editor form.)
  3. The object dropped onto the form is now selected in both the Property Window and PEM Editor.
  4. Classes that are opened (double-clicking) now use (if available) the standard code available thru Thor for opening files.  See Managing MRU lists and Source Code Control.  
These are all minor changes, actually, with very very little code written.

I've been thinking about what else I might be able to accomplish.  (I like tinkering, this is how PEM Editor started).  So, some ideas:
  1. I find the organization of the TreeView to be all a jumble, not taking advantage of all that TreeViews offer.  I think that having root nodes that are the baseclasses, so that all the classes with the same baseclass would be grouped, would be a vast improvement.
  2. Unless I have it wrong, there does not seem to be a way to include all the classes in a project.  I would think that would be highly desirable.  (Apparently, adding a project adds ALL the files.  No doubt there is (was?) good reason for this, but I would think that in a class browser there should be some way to show just the classes.)
  3. I am seeing an occasional bug where the icon for some nodes is not shown.  I'd like to fix that.
  4. Is there really no way to drag a class directly from the TreeView node, without having to resort to using that obscure icon?
I have no idea which of any of these I will implement.  And, I wonder if there are other good ideas out there that I am not aware of.


  1. Regarding point 2. the button to the right of "open" (has a "+" on it) adds another classlib, allowing to have all the classes of those classlibs in classbrowser's threeview.

    It would be great is ClassBorwser will be enhanced, there is a ClassBrowserX in vfpx but i don't know for sure what enhancements it has.

    About enhancements:
    1. Alternate views (standard, grouped - i'd like to group some classes based on their purpose, etc. )
    2. Prevent the deletion of a parent class (or at least show the child classes as 'orphan')
    3. show dependencies (a number, what depends on this class - objects in forms, objects in other classes - relative to current project)

    Markus Egger had some interesting ideeas :)

  2. Eduard -- thanks for your post.

    I am indeed of the Open+ button, which allows adding classlibs one a time. I was thinking of a more automated method of doing so -- I want to just snap my fingers!

    As for your suggested enhancements:

    1. I think alternate views would be a great idea, but I have no idea how and where the definitions of these alternate view would be created and saved. (The idea of grouping by baseclass works on existing information.)

    2. It should not be hard to prevent deletion of a parent class ... if the child classes are currently appearing in the treeview.

    3. Essentially then a count of how many times is used throughout a VCX? Clearly this would have to be an option, but tell me more.



  3. Hi Jim,

    Ken Levy wrote the Class Browser and is pretty active on the UT these days. I'm sure he'd be happy to discuss any decisions he made originally.

    Also, years ago, someone wrote a Class Browser plug-in called AddInfoX that I think is essential. If you startup this project, perhaps that should be integrated.

  4. Hi Jim!

    All "components" in a project are distinct designs for entities that come into existance at runtime.

    The designs do not have to be physically organized into procedure libraries or class libraries for the exe. That physical organization is only for the benefit of programmers, and is to me, all too often not very productive or even counter productive.

    The components do need some form of organization, but not a physical one. The class browser can let us create virtual folders and virtually group components together in different ways, at design time, without having any impact at runtime. It would also be very cool to have it able to ignore the physical organization. By that I mean if the module num2word exists in a procedure library, but I need it for a task, I could show it in a virtual folder. That would save me a lot of time looking at large lists of a) individual files in the project manager b) individual procedures/methods in the DocumentView.

    The missing features that have come to light from my various discussions on this topic are:

    building an exe from the distinct set of components - regardless of the virtual organization - from the class browser.

    packaging a set of parent/sub classes and/or udfs/procedure libraries etc for sharing/distribution with other programmers regardless of physical organization.

    significantly speeding up the class browser instantiation.

    I look forward to your thoughts.

    Mike Yearwood

  5. Mike --

    Thanks for your comments on this.

    This particular project has been on the back burner now for a long time and I do not know when I will return to it, but I will certainly keep your comments in mind.

    1. Here's another twist on my comments which just came up. I'm working with a class to get data for a report frx. The class is in one folder and the frx is in another. Digging in the different folders is wasting time.