SubForms

[Andreas Pfeiffer]

Hi Kevin,

I assume the subform on the next page is not instantiated yet when you are trying to send a message. Therefore you will not be able to get a reference to that instance. Only when the page will become visible it will create the instance inside the subform field.

My advice is to get rid of the page pane and use one subform that loads the data itself. Add a control (i.e. tab strip) that simply assigns the $classname of the subform. Every time you do this its $construct will be executed and from there you can call a method in the main form to get information from it and rebuild its own data. Note that $multipleclasses needs to be kFalse. Otherwise the instance will stay alive and you cannot rely on having its $construct executed when the the $classname is assigned.

You may want to check out the contacts web application sample library that I posted in this forum. It uses this technique. It does use a paged pane. However there is only one sub window on page two and this one gets dynamically assigned.

Hope this helps.

Best regards,

Andreas

omnis.net

Contacts Web Application - Omnis Forum

This is the Contacts Web Application created as a demo version for the Madagascar ODC event. You can download and run it with the Omnis…

[kevin]

Hi Andreas,

Thank you so much for your insight and quick response (as always).

So, to summarise, Omnis Studio: –

* Does not cater for more than one active or current subform at anytime

* Does not permit you to change the current subform

* constructs subforms AFTER the main form has been instantiated (the reverse of desktop equivalents).

I was hoping to approximate the behaviour/appearance of equivalent desktop windows and subwindows.

I use subwindows and subforms where there is a need to display the same data in different situations – without having to duplicate the window/remote form in each case. Standard stuff I believe.

I ran some tests by creating a tabpane on a simple remote form and placing a (different) subwindow on each and tried to set a reference to each subform using $subint. I discovered that I could set a reference to the subform on the 1st pane by default. However, I could not get a valid reference to the pane until after the 2nd pane had been opened.

Once the 2nd pane had been opened I could then set a valid reference to the subwindow (using $subinst). Furthermore, the reference to the 1st subform seems to persist. This is what I was looking for. I will have to run some more tests to check the downstream results.

This then leads to how to use $loadfinished. It is not clear how or when you use this method. Do we have to call this method repeatedly until we get an answer? Do we over-ride it and set a flag of our own? For instance, after opening the 2nd pane (and thereby instantiating the subform on that pane) how do I invoke $loadfinished to know when it is OK to set a reference to the subform?

I know this is not in line with your suggestion but I would like to explore this methodology to see if it is viable – unless you have already been down that road and discovered a dead-end.

Once again thanks for your valuable advice.

Kevin

[Andreas Pfeiffer]

Hi Kevin,

very well spotted. Yes Omnis Studio allows you to have multiple subforms on a form and you are able to address them from outside once they are constructed. For performance reason the subform on the pages that are initially not visible are constructed once they become visible the first time.

You could check if the instance is there using a $cando property on the method. For example:

If $cinst.$objs.sub.$subinst().$load.$cando
  Do $cinst.$objs.sub.$subinst().$load(myID)
End if

The $loadfinished is not something you would call. This method is automatically executed once all subforms have been loaded. The problem you face here is that it won’t be executed until you make all subforms become visible – meaning you would need to change the paged pane. You can see $loadfinished like the $construct. You override it and then this code will be executed once all subforms are loaded. It would be much easier if you do not control the behaviour from the outside of the subform. Let the subform do its own job. Once it becomes constructed it could call a method in the container form.

Btw. this difference behaviour of the remote classes did lead me into slightly different development paradigm and in return it led me change my development style for fat client windows as well. I discovered that it is much more OO when bringing the power to the subwindows/forms rather trying to control everything from the outside.

I hope this helps you.

Best regards,

Andreas