>Dorin,
>
>[Seems that you are trying to make a container to behave like a form :)
>Why not using forms without titlebar? I've done this for an outlook style interface with top level form and forms instantiated on right side of main form. ]
>
>You are correct, we are trying to make a container behave like a form. And, I like your idea. I have to admit, I did not realize you could turn off the titlebar on a form (DUH!). One thing that is nice about your solution is that allowing users to move containters is a tough proposition. Allowing them to move forms is a walk in the park.
>
>Do you foresee any gotchas in using this methodology? Like data sessions issues or anything like that?

Hi Scott,

I would double Dorin's idea of forms without title bars. This is easier to
implement having in mind need to have private datasessions for each.
Now I don't understand why would you remove title bar if you plan to alow user to freely move forms. Why don't you simply let form behave as they normally should in standard window apps ?

In addition to Dorin's suggestion about having form with private datasessions for each form ('container') I would also suggest to have look at session object. It basically creates private session in code as an object.

I use Session object extensively with great success and satisfaction up to now, as it alows me to keep most of BO code in PRG files, while UI (forms) are practically codeless except for calls to underlying session objects. Next to easy maintenance (99% of BO code is in single PRG per project)
it also alows for very flexible form handling (Mimicking formsets withot known formset problems)
Once you instatiate session object you can call any number of forms and they
can all reside in session object that called them. Forms would naturally use
default session and don't really have to open any tables as all this can be done within session object (in code). Beauty of session object is that once
it is released all open tables residing inside are automatically closed. (Watch for dangling obj. refs only)

Consider folowing scenario ;

define class myBO as session

procedure init
   set deleted on
.
.
this.OpenTables()

procedure OpenTables
  use ...
  use ...


procedure ShowModelessForm
   do form FirstForm.scx with this 

procedure ShowModalForm
   do form SecondForm.scx with this to ok_pressed  



Procedure SomeDataProcess
   wait wind 'Process something'


enddefine

Now in init of forms you can add one parameter to receive reference to underlying session object that instantiated this particular form, and you can store it to some form property in order to be able to access methods
in underlying session object. This way you get unlimited *formset* (or rather *Set of Forms*) being cross-connected via underlying session object and all residing in private datasession with all code kept in PRG.

To make all this work on forms side;

*In form init method;
lparameters oBOSession
=AddProperty(this,'oDataEngine')
this.oDataEngine=oBOSession

Then try adding some button to that form, and from there issue folowing
call

*Some button Click
thisform.oDataEngine.SomeDataProcess()

So now, to plug all this together; You can simply place calls (like shown below) on that 'MasterForm' of yours (buttons,tree or whatever) and this way run various bussiness functionality sets which can all have their own session.

**From master form (buttons,tree events,menus etc)
local oBO
oBO=CreateObject('myBO')
oBO.ShowModelessForm()
*or
oBO.ShowModalForm()

Or even better turn above code into some object factory function or object to instantiate them this way.

So advantage which 'converted' me to this scanario over plain forms with private DE sessions is;
Extremely efficient form2form communication via underlying session object, better isolation of data processes (tiers) , better control over set of related forms, and much easier maintenance within single PRG file versus digging for code in form methods scattered anywhere in between 20 and 120 scx files <g>


Try and see if it suit you :)

HTH
Sergio