Mastering InForm: select a previously-placed Frame

[Qwerkey]

Fellippe, in the UI Editor I do not seem able to select a previously-placed Frame.

In the video, I am editing a previously-created project (not a new project) and I have just added Frame "11-Body Data" which is selectable by clicking.  The pre-existing Frame "Simulation Type" appears to be no longer selectable when I click on it.  Clicking anywhere in this Frame selects the underlying PictureBox.

Is this a quirk of InForm or user inability?

Incidentally, in your next issue of InForm would it be possible to have the UIEditor with context menu (in Windows) so as to open existing projects straight away?

Richard

[FellippeHeitor]

It shouldn’t happen. Can you attach the .frm file for me to have a closer look?

In the meantime, you should be able to use TAB ato select hard to reach controls.

BTW, is it all black on purpose?

About loading forms, the next release will allow you to (I) double click any form file in explorer and have it load in the current open instance of InForm or (II) drag it onto the editor for quick loading.

[Qwerkey]

It shouldn’t happen.

Well, it jolly well does!  Form attached.  You will see that some Frames are Hidden prior to Run Start, but none of the Frames seem to be selectable by Clicking.

I had forgotten the Tab usage (that's another thing in which you have done the same as in Visual Basic - I should have remembered).

The PictureBox is supposed to be (near) black.  It will be the dark background for the interacting gravitational bodies.

Richard

[FellippeHeitor]

The problem here is the order of creation of controls. InForm will reorder frames so they are created first (since they are containers) and that ends up placing your picturebox control "above" the frame, even though it gets properly drawn below. The fix for now is to actually use the TAB key to get to the semi-covered control, sorry for the trouble.

[Qwerkey]

Another problem (property, rather) of Frames.

I previously could not access a Textbox withina Frame that was in the same position but Hidden/Unhidden as another Textbox.  So I created a separate Frame for the two different (but alternative) Textboxes.

So the two Frames (SimulationLimitTimeFR) and (SimulationLimitCyclesFR) were in the same position but Hidden/Unhidden.  But then I noticed that one of the Textboxes could not be accessed with a Click and the value could not be updated.  And I later found that the Frame (SimulationLimitCyclesFR) was actually attached to the Frame (SimulationLimitTimeFR) in UI - if (SimulationLimitTimeFR) was moved, so did (SimulationLimitCyclesFR).  Then I manually edited the position of (SimulationLimitCyclesFR) to somewhere outside of (SimulationLimitTimeFR).  But now I find that (SimulationLimitCyclesFR) is "Disabled" - its caption is greyed out and the Disabled property cannot be changed in the UI.

That will become clearer if you run the attached.

So, what we have learned (or, in my case, be confused by) is that no Frames or controls within Frames can be placed on top of each other at Design Time (I haven't discovered if they can be successfully so placed at Run Time), and I've changed the Form so that all items are separate.  It does make the initial data setting look rather untidy for some Simulation types, but everything is now coming together.  I now have the task of converting the vast number of Control code statements into Fellippe's recommended method.

Richard

[FellippeHeitor]

If at run time you place a frame on top of another no issues will arise, as I told you before. I have done that with UiEditor itself, when you see an Open dialog and also the Z-Ordering dialog. These frames are placed offscreen during execution and moved to 0, 0 when invoked via File->Open or Edit->Z-ordering.

Before I make any changes to that issue, make sure not to drag a frame into another. It shouldn't happen but it is happening, so it'll take some research to squash that bug.

However, if, at design time, you create your two overlapping frames in a non-overlapping fashion while you design them, then change their coordinates without using the mouse (by entering values in the editor in their Top/Left properties) you should be able to bypass the bug for now.

Another thing: You could manually fix the buggy .frm file that InForm output by removing the last parameter in the __UI_NewControl line when your frame was created and making it = 0. The last parameter is exactly an indication of the parent control.