Sorting the object list of a form by its objects. 4

[german12]

I created a form with lots of command buttons on it and then I added an option group to this form.
Later, a few more command buttons were added. If I want to change the code for a command button,

I can see this command button with all the other objects in a list when I click on a command-button within development-mode -
but this list is obviously sorted by time so that the command buttons created first are visible, then the option group and only then the followed by command buttons that I added later (after the option group was created).
Question:
Can this list be sorted so that all command buttons appear together?
*******************************************************************
Example:
Now:
cmd-1
cmd-2
optiongroup
option-1
option-2
and more options

cmd-3
cmd-4

but:
I want it so:
cmd-1
cmd-2
cmd-3
cmd-4
optiongroup
option1
option2
and more options
*********************************

Then it is easier to find the right command button to change.

Thanks
Klaus


Peace worldwide - it starts here...

 

[TamarGranor]

To the best of my knowledge, there's no way to do that.

That said, you can type start typing in the dropdown list in the PropSheet and the ones in the Method Editor to quickly get to the control you're interested in.

Tamar

 

[Chris Miller]

How about not picking the object in the code editor window, instead close that and double click on the form object you want to edit?

You can also combine picking the object on the form designer with the properties window with the Methods tab activated:
Clicking on an object (single click) activates it in the properties window combobox, thus the methods/event of the selected object are listed in the Methods tab. Then you can pick the method/event you want to edit in the properties window and navigate there this way.

It's not unusual to have several windows open all the time during development: Project manager, properties window, command window, to use them in conjunction.

Chriss

 

[xinjie]

Your understanding is not entirely correct, although it is in line with your observations.

They are in TAB order at the same container level, in fact.

You can see the order of the list as you want it to be if you change the control's Tabindex property.

Of course, you can achieve the same goal by putting the control in front or behind in an interactive way (The results are only displayed when you open the form designer again).

You can change the tools-options(List display count) if you want to see more controls in the list.

My English is very poor. The above responses were made using an online translator. I apologize if I misunderstood your problem.

 

[IlyaRabyy]

How about this:
Open your form in the (visual) Form Designer,
Move your controls to the desired places,
Assign sequential Tab Order number (I usually make interval 10, e.g. 1, 10, 20, 30, etc.)

VFP is called "Visual" for this very reason: visually build the GUI objects.

HTH.

Regards,

Ilya

 

[TamarGranor]

Ilya - as I understand Klaus's problem, it's not about tab order, but about the order things appear in the property sheet and method editor.

Tamar

 

[german12]

Tamar - you got it.
see it below.
The properties of a form shows first some cmd_buttons then an option-group and then again cmd_buttons.
That is it what had disturbed me, when I wanted to find a certain code.
I wanted it sorted by object-type.

Peace worldwide - it starts here...

 

[german12]

xinjie - your English is well understandable.
Thanks for your hints.

You can change the tools-options(List display count) if you want to see more controls in the list.

That one is a good help - I did not know it before.

Klaus

Peace worldwide - it starts here...

 

[Chris Miller]

I wanted it sorted by object-type.

That's not possible.

And showing more items will also not help in case of more complex forms. You better get used to having the properties window open while you develop, it's always useful. Also see the advice I already gave about using it to navigate directly into the method/event you want to edit.

Picking an object on the form makes it the active oibject in the properties window, and in the methods tab you get the list of methods and events, double clicking on one of them brings you into the editor.
The click event is the one you can also get into by double clicking on the button in the form editor. But when you directly want to get into the GotFocus event, for example, the property window is your entry point of picking precisely where you want to go into.

Chriss

 

[Chris Miller]

Just another hint: If you want all buttons grouped to get into every buttons click event faster and program something into it, what you actually want is to program that once into a button class instead.

Chriss

 

[german12]

Thank you very much Chriss.
I have to admit that you can make adjustments to an application much more effectively if
several windows are available at the same time
arranged appropriately on the screen. I have never done that before - it avoids a lot of unnecessary opening and closing of windows and it also makes it much easier to concentrate on one point during development.

Klaus



Peace worldwide - it starts here...

 

[ggreen61]

If I understand correctly,`you want the objects to be sorted based on the type; i.e., commandbuttons grouped together, textboxes grouped together,etc. I wrote my own custom editors for VCX, SCX, PRG, MNU and the VCX/SCX editor sorts by alphabetical order for the objects. I have the naming convention to name textboxes with the prefix txt, editboxes with the prefix edt. Each object type has its own unique three character prefix. I think this results in a sort order that you are asking for as shown below.

Greg

 

[Chris Miller]

Klaus should answer for himself, of course.

The special need I saw was tackling all button clicks, for example, and while you're in a click event of one button, the seemingly shortest way to get to the click of another button is, if those buttons would all be grouped in the objects dropdown list the editor provides.

If you take two steps back you'd even realize that this pattern of needing to go into all type X objects to edit their method Y is having a class that centralizes that, because the need to have these edits points out weak or even no use of the oop principles of reusability of (class) code.

Anyway, the other side of it is easy navigation betweeen the methods of all the forms objects and the easiest way to do that is the use of form designer, property window and code editor, the dropdown list becomes a secondary or even completely unimportant tool, that way.

I guess most people would argue that the best solution nevertheless would be to have all code in one file editable. Because needing three/four, maybe even five windows open all the time, that requires a workstatoin with two or even three displays, and I would agree, yes, that's how the wokstation of a developer should look like.

But there is a point of the "all code in one editor window", when you also think of the document view you can open up in parallel and use for simple navigation within this one likely vast and still not easy to manage code window, at least scrolling is no good way of navigation. It would drop the need of the number of windows to have open at all times and would allow those more into the procedural programming paradigm to program their way.

I only use the document view when editing larger PRGs, which could contain class definitions of class families I maintain that are based on non visual base classes like sessions or programs that are function/procedure libraries, and a whole form/class editor window would extend the usability of the document view, that's something I wouldn't deny to use. It would make it harder to use the superclass switching, though, that would need to swap out depending on where the cursor is within the code.

I always think of the downsides of the IDE as guides to OOP programming. It's not very fruitful, I think, otherwise such questions and desires wouldn't come up that often. It's fair to say that VFP is still supporting both procedural and oop prgramming. The one thing that annoys me the most as programmer in the oop camp is the inability to edit a class while also having a form or any other item open in editing, that has instances of the class. The technical need to have no instances of a class before you can edit it is really the worst design flaw of the VFP IDE.

The two points that I would tackle, if VFP would still be a continued poroduct would be:
1. Single full code editing of "code behind" with an extended document view and context sensitive superclass tool
2. Class editing, no matter whether instances of the classes are loaded or not, in a way that those instances would also be upgraded in the cache once you save and compile the changed class.

Point 2 would - I think - also sort out the more general problem of editing code while it runs, in the debugger, for example. Or vice versa, the ability to make running code editable would also allow class editing at any time.

Chriss

 

[ggreen61]

Chriss--

My SCX and VCX editors provides for your 2nd point:

The two points that I would tackle, if VFP would still be a continued product would be:
1. Single full code editing of "code behind" with an extended document view and context sensitive superclass tool
2. Class editing, no matter whether instances of the classes are loaded or not, in a way that those instances would also be upgraded in the cache once you save and compile the changed class.

I think the 1st point could also be solved (however, I am not sure what specifically you are asking for). Having the code base for the editor allows for any improvements that are desired. The VCX editor also has the ability to edit all classes in a VCX or a single class.

The downside to my editors is that only the PRG and MNU editors can be invoked as alternatives from the project file since these can be replaced via the _MENUDESIGNER and TEDIT in the configuration file. To get around this problem I also created a project manager that will invoke these replacement editors or the standard VFP editor.

Greg

 

[Chris Miller]

Are you sure you understood what I want in point 2? There is no difficulty in editing a PRG or also a memo of an SCX or VCX in a third party editor (provided you later put it back to where it belongs). It still won't at the same time update what VFP has loaded into memory.

The 1st point is something I imagine I could also do, it's just a bit fiddly, you can gather all memos of an SCX (or of the records of a VCX that belong to a class) and provide them in one editor window, then later put the parts of the code bacck into the memos they belong in, provided the user doesn't modify the code in an unhealthy way, which could happen. The hard part is keeping track of which parts of the overall code belong into which records. You could go the easy way and allow editing of the source code memos as they are, that's not merging them into one single code editor, though, which would be the charme of also enabling navigation through the whole code with the Document View window, which in turn will only navigate inside a VFP editor window, not in something you can specify with TEDIT. I know that config.fpw option, it never was something that would be useful to me, as it doesn't cover many aspects of the internal editor.

Chriss

 

[ggreen61]

Chriss--

Yes, I understand the desired feature. The VCX or SCX editor opens the form/class directly from the SCX or VCX files. I do not edit a separate PRG representation of the SCX/VCX. I open the VCX/SCX as a table and then load into the editor; the save process writes directly back to the VCX/SCX. The VCX or SCX is opened by the editor in shared mode to allow for another user to be able to open the SCX/VCX in read-only mode at the same time. Since I do not create an instance of any class in the editors, I can also edit a class that is used in another form (being edited) and have both editable at the same time. The editors currently allow for editing all code and properties. I allow for an unlimited membername list than the standard VFP editors (this is saved into the user field) to retain the uppercase/lowercase of the properties/methods names.

But to your point of the class being in memory; if it is, then I can only open in read-only since I cannot lock the VCX for the initial opening (I do a FOPEN() on the VCX or SCX to check if it is being edited by someone else and then immediately do a FCLOSE()). So, as long as you are not editing a form in standard VFP, but instead using my editor, you can open both the form and a class in the form at the same time for edit fully in my editors. You can open a class for edit in my editor first and then edit a form that uses the class in standard VFP. But if the form is still open in standard VFP, when you save changes to the class, the changes are saved but the class cannot be compiled at the end of the save processing. The form has to be closed to allow for the compile to succeed.

A visual representation of the object's layout is available but is not editable (this part to allow for layout editing has never been finished; as such, I use the standard VFP editor to do the layout and then use my editors for the coding). There are some advanced layout capabilities coded, but there is not any save-back of changes.

The development of these editors originally started back around 2006 (just before the announcement of the ending of VFP). The past 5 or 6 years has seen very little change to these editors as they serve my purpose.

BTW -- over the years I have had VFP corrupt (for reasons unknown) my VCX or SCX using the standard built-in editors. However, I have never had a corruption of my editors to the SCX or VCX files. Note also, you cannot add objects or delete objects in my editors; only the method code and properties are editable.

Greg

 

[Chris Miller]

Okay, now I understand. I was taking for granted a form is open in the VFP form designer, which already locks out the possibility top edit classes of controls that are shown. Having your own complete designer, but lacking the visual editing, hm. I wonder if that would work out well. I like being able to work on both visual and code part, otherwise I would feel demoted about the full potential of editing both things. It's a bit more work to correctly visualize a form as the visual designer does. They also don't run the code, though, at least you need quite some trickery to run something at design time, not using builders.

Chriss

 

[ggreen61]

Chriss--

Yes, the layout did provide a challenge. Below is a form that I have; the first shown is the layout in standard VFP edit mode and the second is the layout in my editor:

You will immediately note the custom command buttons are only represented by a rectangle. The selection capability of objects is fully working; the properties of objects is shown to the right in a tabbed view. There are some builders for the properties and they are selectable the same as standard VFP.

[Edit] I had originally opened old version of the form in my editor; I have updated the screen shot with the same form version as standard VFP screenshot.

Greg

 

[german12]

Greg and Chriss,
Thanks for your discussion on my original question (sorting the objects in a form according to their types.)
I imagine the editor Greg has written for this purpose has caused a lot of work, and this will be particularly helpful for complex projects.
It would certainly not have been a problem for the developers of VFP to incorporate this sorting function - whether it is needed or not, sometimes it makes sense when looking for errors, in my case it bothered me even though it was only a small project.
It's not always helpful - Chriss also explained it in connection with classes and subclasses, but if you can immediately see the source code, for example for a group of command buttons, as in Greg's Editor, then that can be helpful.
However,I confess - I would not be able to write such an editor.

Klaus

Peace worldwide - it starts here...

 

[Chris Miller]

looking for errors

When does it happen, that you look for an error in any button?

The tools for fixing errors are error handling and the debugger. And they will tell you exactly which button (or other object) has an error, I don't see the grouping of objects as helpful for that specific purpose. It's helpful in a more general way, but also only, if you need to modify all same object types, and that's better solved using classes, actually.

One very handy way of error handling is to put a programmatic breakpoint into your error handler, so you can step to the line of error in debugging.

Run this:

On Error myerrhandler()

Set TablePrompt Off
Use nonexistingtable
Use

Procedure myerrhandler()
   Local Array laError[1],laStack[1]
   =Aerror(laError)
   =Astackinfo(laStack)
   * inspect those arrays in the locals window of the debugger
   If _vfp.StartMode = 0 && running within the IDE
      Set Step On
      Retry
   Endif

Using Retry will bring you back to the line that errored, when you testrun code within the IDE. If that happens in an EXE what's missing is storing the error information in an error log table or text. This is not to demonstrate good error handling, just the aspect of enabling to live debug an error by using RETRY.

I think you indicate the case when you found an error and know all your buttons will have the same error, as you copy pasted code, so that RETRY only brings you into one button nd not all of them (and there is no editing of code during debugging, anyway).

Well, but that's the general error of not using a button class instead of repeating code. And if the code would be so individual you can't put it into a single class, use two or more. On the other side, if you have repeated errors it points out that code is shared among multiple buttons.

The size of a project doesn't make classes over the top. It's always good to centralize the same code into a class, so errors are not copied all over the place, but also stay localized in one point to fix.

PS: One more thing about why to use SET STEP ON and not SUSPEND and why to use RETRY:
1. SET STEP ON brings up the debugger and suspends code execution, it's a programmatic break point. I know Tamar always points out use SUSPEND instead. Well, here I'd highly recommend SET STEP ON, because it will bring up the debugger, no matter if it already is open or not
2. RETRY brings you back to the line that errored, and at first blush that sound unpractical, as the line will error again.
Yes, it most often will, the reason to use RETRY is not to actually retry but to get you to the point of error, no matter if it's in the middle of code or the last line of the method/event/procedure/function failing. If you'd RETURN, you'd return to the line after the error, and when the error is in the last line of code of something, you don't get to the place of the error, but could end up at READ EVENTS, in the worst case, if the error happens in the last line of a button click that was happening by a actual click, because after that VFP would return to the READ EVENTS line. Aside from ASTACKINFO and AERROR info you'd have no clue where the error happened, therefore both SET STEP ON and RETRY for live debugging.

PPS: What to do, when you're at the line of error in the debugger?
Well, you often easily spot the error in code and you can make use of a nice feature of debugging: The command window can execute within the context of the current procedure/function/method/event, which in case of objects does not only mean you can access local variables, as if the command window is within the currently executing code section, you can also use THIS, which normally errors when used in the command window. So you could write the line that errored without an error, execute, then set the program pointer to the next line and continue, confirming your fix works. Now stop the debug session, copy the lat line of the command window into the error line and you fixed it. So the command window is also your clipboard for memorizing the fix temporarily. I'd still rather like to be able to edit the actually running object, whether it's a class, form, PRG, whatever. That's still impossible, but at least you have the command window as placeholder.

Chriss