Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Containers not Forms as the main user interface...help!
Message
From
01/09/2008 00:34:53
 
 
To
25/08/2008 14:19:58
Scott Malinowski
Arizona Fox Software LLC
Arizona, United States
General information
Forum:
Visual FoxPro
Category:
Other
Environment versions
Visual FoxPro:
VFP 9 SP1
OS:
Windows XP SP2
Network:
Windows 2003 Server
Database:
Visual FoxPro
Miscellaneous
Thread ID:
01315051
Message ID:
01343737
Views:
26
>>>Bernard,
>>>
>>>We are still running into issues trying to use private data sessions in containers. I have reviewed both of the articles that you identified in your post and I am not sure either provides the solution we are looking for.
>>>
>>>Please allow me to take a different approach on the explanation and maybe that might spark someone's thoughts on the issues at hand.
>>>
>>>Our application has what we call a work flow form. This form is really an empty form with custom methods and custom properties on it to allow us to control the numerous containters that may be instantiated at run-time. Some have non-modifiable data on them basically as information for the user to view. But, it is nothing more than a pseudo-formset because we will not use formsets and you wil understand why in a moment.
>>>
>>>Once the work flow form is up, the user can right mouse click and a popup menu appears that allows them to open numerous containers that will reside inside the work flow form. The reason for this and not using pageframes as well, is that the user needs to be able to see all the information from the various containers at one time. They can move these containers around to their best advantage, etc.
>>>
>>>We also build a business object, based on a data environment object. This busienss object will contain multiple cursor adapter objects that are needed to perform the functions needed for the business object. Each form and container object has it's own business object.
>>>
>>>As you know, you can only visually use data environment classes on formsets, forms, reports, toolbars and _screen. Well, we want to use them in containers. We want the container to be self-sufficient and totally independent as far as the data goes.
>>>
>>>We are able to use addobject with createobject to create a business object in a container. However, it shares the same data session as the form. This is not good for our goals. We need a solution that allows the data session to be private for every container on the work flow form.
>>>
>>>Is it possible? We are beginning to believe it is not.
>>>
>>>And we are at a critical state of the application, that is, developing business objects like crazy, and we need to either find a resolution or change our design which may affect how we design our business objects.
>>>
>>>Any imput would be greatly appreciated!!!!
>>>
>>>Thanks!
>>>
>>>Scott
>>
>>Hi Scott
>>
>>Maybe you need to look at this from another angle. I now understand what you want and AFAIK only a form has a data session.
>>
>>Couple of things to try. Don't know if they will work.
>>
>>1. VFP9 has a SESSION object.This cannot be created visually but can be created as a PRG file. This object is specifically for having sessions. I have used it in a number of COM DLL's because I needed separate sessions. So you could try adding this to a container and carry on from there.
>>
>>2. A container is just that a container. A form is also a container as is a PageFrame. Maybe you could look at using a form instead of a container. This way you can be sure that each "container" will have its own datasession. Setting Titlebar = 0 will remove the titlebar and it will now look like a container, will act like a container, can be moved like a container, will have more PEM's than a container but best of all, can have its own datasession and DE.
>>
>>To get the containers(forms) to show inside the main form, you instantiate it with NOSHOW then issue
>>
>>SHOW WINDOW MyContainerform in Window MyMainForm and they will become child windows of the main form. Then you can position them as usual.
>>
>>Or visually, set their SHOWWindow = 1 (in top level form)
>>
>>HTH.
>>
>>Bernard
>
>Hi Bernard!
>
>We have been trying to get your second suggestion to work as that more suits what we are tyring to accomplish. My user interface guy is having some difficulty getting a form to show inside the user-defined window as you suggest.
>
>Do you have any code that might show this is done all the way through the process? That is, from the definition of the main form (window) through making the child windows visible?
>
>Thanks so much for your help. I appreciate it!
>
>Scott M.

Hi Scott

I have emailed a sample exe and the source files. These forms use the tables from the VFP \Samples\data directory so make sure they can access them, or change the paths in the forms before running them.

How it is done I have actually documented in an old blog post here:
http://weblogs.foxite.com/bernardbout/archive/2006/05/23/1564.aspx

Basically you have to name the form - that is you have to fill in a name for both forms in the NAME property of the form.
That is how I have done the sample, but you can also do this:

Main form - ShowWindow = AsTopLevelForm
Child form - ShowWindow = In TopLevel Form

You can make the TITLEBAR = 0 to remove the titlebar (it now looks like a container). You will have to add code then to move the form but that is easy.

The sample I sent you has a table open in the DE of the Main form and another table open in the DE of the child. On running and clicking the button, if you have the View window open (Windows\Datasession from the menu) you will see that there are separate data sessions open for each form.

Now how you manage this is up to you but you now have individual datasessions for your "containers"

You can find a number of similar techniques like this on my blog: http://weblogs.foxite.com/bernardbout/

Cheers

Let me know how you go.

Bernard
Previous
Reply
Map
View

Click here to load this message in the networking platform