🚀 go-pugleaf

> 3) The form stack & client's back-button limitations I bypassed stopping use the pageno
> and multi-form schemes. In reality all this application that have almost 700Kb of code and
> more than 30 different "pages" use only the pageno=1. I have multi-form archives (JFM) but
> only one (the entry one) is accessed by the client and the others are just classes
> definitions that the former load when necessary. With this orientation there is only one
> "f.open()" - example :) - when the app is started by a session and only one "f.close()"
> when (and if) the user clicks the "end session" button that I put in the Home Page (as the
> banks do). In no part of the application there is a _sys.scripts.run.

Here my question:
I thought, that form stack is created evary time - just because You open
new form - am I wrong?

> 5) With the benefits of doing the iten 3 above, I could use as many frames as I did need.
> There are also pop-up windows, automatically opened and closed windows, etc. And all of
> them are updated with data came from IB and all of them can post data back, with no one
> conflicting or been missed in the process. Can you imagine 3 frames plus 2 pop-up windows
> operating in the same time from one IB application ? It works.

Here next question:
What about security - or may be You doesn't use it?
In my applications I use security objects from built-in solutions of
Borland - it is very hard use it in frames because of authentication
should be made only once and here it will be for every frame. 
Have You any of such features in Your app?

I find that there is some possibility to provide security from application
using frames by using second hidden field - there is stored session id -
it can be passed to next forms and this way it is recognizeable where is
client. But I don't know if there is a posssibility to use objects from
this session in others sessions by refferencing to them

Any way I'm impressed by Your work and think Your notes will be very
helpful.
	Greetings
	Rem

 

------------------------------------------- 
Remigiusz Sokolowski      
e-mail: rems@gdansk.sprint.pl
-------------------------------------------