In LOB. how is the order of forms as elements determined?

Here is my DB and these forms: “Acteurs”, “Actrices” and “FilmsSeries”.
,
Forms DB
.
Here is the “FilmsSeries” form and its 3 main forms: “frm-FilmsSeries”, “frm-Filtre”. “WDSettings”
.
Form FilmsSeries
.
Here, the “Acteurs” form and its 3 main forms: “frm-Acteurs”, “frm-Filtre”. “WDSettings”
.
From Acteurs
.
Finally, the “Actrices” form and its 3 main forms: “frm-Actrices”, “frm-Filtre”. “WDSettings”
.
From Actrices
.
In a Basic procedure, these two lines of code are used:
.

     oElement = ThisComponent.DrawPage.Forms.ElementNames
     sElement = oElement(0)

.
oElement (object variable) places the list of elements corresponding to the names of the three main forms of each of the forms in the database according to the open form.

sElement (text variable) sets the corresponding form name to ElementNames(0).

For each form it looks like this:

Form 1 (Acteurs): “frm-Acteurs”, “frm-Filtre”. “WDSettings”


.
Form 2 (Actrices): “frm-Actrices”, “frm-Filtre”. “WDSettings”
Form Actrice (sElement)
.
Form 3 (FilmsSeries): “frm-Filtre”, “frm-FilmsSeries”, “WDSettings”
From FilmSeries (sElement)
.
For the (Acteurs) and (Actrices) forms, in the form’s ElementNames variable, the ElementNames(0) or oElement(0) corresponds to “frm-Acteurs” and “frm-Actrices” respectively. However, for the (FilmsSeries) form, the ElementNames(0) corresponds to “frm-Filtre”.

For what reason in the form “FilmsSeries”, the form “frm-Filtre” is considered to be ElementNames(0)? However, in all three forms, the main forms are arranged in the same order.
.
From Acteurs

From Actrices

Form FilmsSeries
.
In the current situation, this requires me to use additional lines of code to check the name contained in the variable (sElement) and act conditionally, which I would not have to do if the ElementNames(0) or sElement was either: “frm-Acteurs”, “frm-Actrices” or “frm-FilmsSeries”.

Is there a way to ensure that for the form (FilmsSeries), the ElementNames(0) or sElement may = “frm-FilmsSeries” and not “frm-Filtre”?

What determines the order of forms and subforms as part or element of a form?

Seems reading of the form names will set the name in alphabetical order in a array, asked by a macro. Has nothing to do with order of the names, which will be shown in the form-navigator. This order of names will show an order by creating a form. The new created form will be out to the last position.

1 Like

Thanks @RobertG

What you’re saying really makes sense. So the situation is about how an array works or is organized in Basic language.
.
I would have thought that Base also associated a number with a form as an object. But, it’s okay, it’s not a few lines of additional code that will weigh down the database.
.
Thanks again!

@Renel,
.
I do not think alphabetical order plays a part.
it seems to me that when an inner form is created or renamed then it’s timestamped and it’s the timestamp which dictates the index number.
you can easily test it out yourself
.
create 3 inner forms in alphabetical order and name them K, F, J.
.
Properties will show: (000) = K, (001) = F, (002) = J.
.
rename F to A.
.
Properties will show: (000) = K, (001) = J, (002) = A.
.
rename in this order J to Y and K to X
Properties will show: (000) = A, (001) = Y, (002) = X
.
FOR EXAMPLE WITH YOUR DATABASE:
if you rename the inner form “frm-Filtre” to “frm-Filtre1”
then it should inherit the max index number.
THEN
rename the form “frm-Filtre1” back to “frm-Filtre”

Remember: The position in the form navigator shows this timestamp. The first form, which appears, has been created first. There is no way to sort this after creating if you won’t copy and paste the form to a subfrom and then back to the mainform.

I would never try to get the right form by index. Only by name you will get the form you want.

@RobertG .
the question was:

explicit request was:

the solution is:
created in this order A,B,C.
1
.
renamed A to X:
all indexes have changed
Form(X) originally known as Form(A) which was indexed at 0 is now indexed at 2.
2

.
renamed X back to A:
Form(A) originally indexed as 0 is now indexed at 2.
3

I have answered the question with factual detail and no rules are bent or broken therefore I see no legitimate reason not to get the right form by index.

not true, it’s possible to move form A to any position in the navigator without using copy or paste.

Gentlemen @RobertG, @cpb,
.
The alphabetical order of forms or the order of placement in the navigator window does not appear to play a role in how Basic or perhaps any of the programming languages handle the numerical order of elements in the ElementNames variable of UNO services.
.
I changed the name of the second form to “frm-Filter” and created two new forms using the same name as “frm-FilmsSeries” and changing just one letter to see how the ElementNames variable would be indexed. Here is the result :
.
Screen1
.
Screen 2
.
I don’t really know what to think about it… And you?

I should apologise.
after shutting down the database and reloading, the index sequence has reverted to type and therefore my suggestion is temporary and unviable, RobertG is correct.

Here a screenshot of my system - form navigator:
grafik
Couldn’t move frmFilter to first position. Could only move it into MainForm. See Bug 155790 for this. I have just created many forms by copying the content from one form document to another form document to get the right order for all elements in form navigator, by tabulator and setting automatic control focus.

In fact, it is possible to make frmFilter first. You have to work around the Bug by placing MainForm in frmFilter (as a subform); move it again by dragging it onto Formulare and it automatically takes the last position regardless of the number of forms present.
.
As for my problem, I managed to restore the desired order by renaming frm-Filtre to frm-Filter. The ElementNames variable now reads like this:
.

ElementNames(0) "frm-FilmsSeries"
ElementNames(1) "frm-Filter"
ElementNames(2) "frm-WDSettings"

.
I was able to eliminate the lines of code that required me to check the content of the ElementNames(0) and take the necessary actions for the Macro to function properly. Now I have a simplified and equally functional Macro.
.
I still don’t understand the relationship between positioning forms in the database versus indexing inside variables like ElementNames() of a UNO service, but whatever, my problem is solved.
.
Thank you Gentlemen for your time, it was much appreciated.

@RobertG,
.
I use drag and drop as shown by Renel.
.
create a new dummy form and drag the existing forms you wish to reposition into the dummy then drag them out again in your chosen order and drop them on 'Formulare.

I have done the same by creating empty forms and moving to this empty form. But this won’t be the same as simple sorting. Sorting should happen in the same level.

Moving only forms will work, but I had many crashes when moving fields from one form to another to get this fields sorted. So I created a new form document and copied from one to the other. Will work. Only bug: Forms will be copied, but the connection from the forms to macros will be lost.

getElementNames:

Returns a sequence of all element names in this container. The order of the names is not specified.

@RobertG,
.
currently there are numerous bugs in Base forms, most of them introduced by LibreOffice developers and ignored by supervisors.
when using a form to input data there are bugs which impact last row, new row, time fields and numeric fields, you can no longer trust in what you see or recommend the use of LibreOffice Base to clients, it’s standing at deaths door.
.
all of my forms and their controls are in the correct sequence which is achieved by using drag and drop.
I drag forms or individual controls 1 at a time, sometimes they shrink in size and are re-positioned, they often disappear from the navigator and recently objects have been prone to losing focus, crashes are frequent and form design has become a nightmare.
.
Base may be free but is no longer a viable gateway to database development.

.
You’re probably not completely wrong. But I would tend to support the following Villeroy comment :
.

Base is a cheap and over-simplified frontend. It is very well suited to serve data from already existing databases to office documents. It provides input forms in the 90ies style, fairly well suited to edit interrelated table data (one-to-one, one-to-many, many-to-many relations). Macros are a no-go. If you need macros to work with your database, the database is poorly designed.

(Villeroy, Database use - What's the best way?)
.
It’s probably that I’m using way too many macros and within them the choice of UNO services are not always the best or appropriate. Which can make things more complicated unnecessarily.

@sokol92
.
That’s right, ElementNames returns an unsorted list, so the choice of this variable linked to the “thisComponent.DrawPage.Forms” command was inappropriate.
.
This command gave me access to the form names only from the list of elements which is not sorted. Bad choice.
.
Since the Macro is executed from a button, choosing the event as a command allows me to access the form associated with the button, hence its name, this would have the right choice to make from the start. Here is the command: “sFormName = oEvent.Source.Model.Parent.Name”.
.
It’s my mistake.