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...

 

[Chris Miller]

Greg,

I imagine the challenge of the visual designer is that creating objects from the classes/classlibraries or OLE classes specified in the SCX/VCX records will execute their init and thereby start things you don't want to run in design mode.

The only workaround I see is creating a builder (on the fly) for the class or form you edit, but that would inherit all the problems of the usual visual designers, right?
Forget that question, you first need to have something open in design mode, before you can start the builder for it, right?

Chriss

 

[ggreen61]

Chris--

You are right if I used the actual controls in the forms or classes. Too many problems would occur as they would be fully active. I suspect that VFP has a 'special' design environment that prevents the control's events from firing but allows for the control to be built. In my case, I created my own set of controls to be displayed. I needed this to be able to use the mouse events for resizing, moving, etc. My controls 'inherit' the display properties of the original control such as width, height, color, caption, etc. The problem is with the control class -- it is a single container that can have many parts inside. This class was more difficult to drill into for display purposes only. The container and pageframe classes are easier to handle; I can drill into these to add the controls for display.

Greg

 

[Chris Miller]

Klaus,

one last thing about the order of objects in the code editor "Object" dropdown list - this one you posted:

Tab order is not influencing this, nor does it depend on the position of the controls, it's also not just the order in which controls are added, though that's closest to the truth.

It is listing them in phyiscal record order of the SCX table, which normally is the order in which controls were added. But there is one design tool that changes this: When you use the menu item "Bring to Front" or "Send To Back" in the "Format" menu, as xinje suuggested. You could experiment with that to find out how it effects the order. It boils down to the recno the objects have.

So instead of cumbersome object by object usage of the Format menu items, you could reorder the records physically to get them in the order wanted. There's no simple tool to do that and even if there would, you can't reorder records in any order, as controls within containers or pages may cause trouble, if their records are before the container or page they are inside. I haven't tried if it would cause damage and, of course, it would be just a matter of trying it out once. But I wouldn't swear on it working in general, if it works on a small example, so I wouldn't recommend that record rearranging unless it could be done by means of the "Bring to Front" / "Send to Back" menu items, which work within the records that belong to a parent object.

So lets give an example where that would matter: If you have a pageframe with 3 pages, each having 2 buttons separated by an optiongroup, the "Bring to Front" / "Send to Back" menu items would allow you to bring the optiongroups as third element of each page, but the object list would still not group together all buttons, it would only allow to put the optionsgroups as third object within each page.

So, all in all, you could risk side effects maybe only showing in later continued development of the form, by sorting records by baseclass mainly, or you could use Gregs alternative form editor with the pros and cons, one pro being the ordering of objects. Besdes usage of the designer in conjunction with the properties window as I suggested earlier, too, and you already agreed has accelerated your IDE usage.

I would not be able to write such an editor.

It's been done already:

GitHub - ggreen86/VFP-Editors: VFP Editors for SCX, VCX. MNU, PRG, and DBF files; also Table Browser and Project Manager Replacements

VFP Editors for SCX, VCX. MNU, PRG, and DBF files; also Table Browser and Project Manager Replacements - ggreen86/VFP-Editors

github.com

It has some more advantages as discussed, because you can then edit classes while editing a form which uses theses classes, which is a great deal - enabling parallel editing.

Chriss

 

[german12]

Chriss,
thanks for your deeper information.
I didn't know that there was also a link for ggreen86's note to get to the editor. It was not visible in his 1st statement.
I'll take a look at how to download it.
greeting
Klaus

Peace worldwide - it starts here...