Hi Jeffrey,

I don't believe the Flash runtime allows reparenting of movie clips, and each view in OpenLaszlo is backed by a movie clip of one flavor or another.

I've heard of people doing something like what you describe with floatinglist -- but a floatinglist's immediateparent is always the canvas since it floats above everything else. Without looking at the implementation datepicker I don't know whether it also floats and parents to canvas, but if it does you may not have to change the parent at all.

Note, however, that datacombobox (new in 3.2) used to "pool" just a few floatinglists and share them between combobox instances. We took that optimization out because we were seeing problems with properly resetting all the data dependencies. My opinion is that this technique is going to be fragile; I wouldn't particularly recommend it. What we did instead was wait to instantiate the floatinglist until the combobox actually asked for it. This is robust and has the same benefit in startup performance.

jim

On Feb 16, 2006, at 10:50 AM, Jeffrey Shood wrote:

I'm working to streamline our application and am currently trying to reuse as many modules as possible at runtime. For instance rather than instantiating dozens of datepickers I'm instantiating one on the canvas and moving it around as needed. However in a more complex app this create issues. For instance a group of windows or a tab slider may be made invisible. While visually the datepicker was made to look contained by the window or datepicker it's visibility is not changed along with the view it is sitting on top of.  To really complete the illusion is there any known way to change the parent of a view.
 
Couple of things I've tried that didn't bring much success...
 
1) Adding the module to the subviews & subnodes arrays it's being overlaid on. Hoping there was some sort of internal mechanism in the view class that loops through these arrays to change visibility of their children when their visibility is updated.
 
2) Created a large number of delegates to try and trap all the possible ways the module would need to be made invisible
 
I can imagine as more teams build larger apps this may be a way to significantly reduce resources. Any hints as to the inner workings of the view visibility and node structure would be greatly appreciated!
 
-Jeff Shood




 
_______________________________________________
Laszlo-user mailing list

_______________________________________________
Laszlo-user mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-user

Reply via email to