FoxInCloud
How to adapt Top-level Form calls and MessageBox calls from a Mains Program file
Gravatar is a globally recognized avatar based on your email address. How to adapt Top-level Form calls and MessageBox calls from a Mains Program file
  n/a
  All
  Oct 28, 2014 @ 07:32pm
Hi guys,

I have a large (mains) program file that hasn't been properly normalised by the previous developers of this app.
ie. there is no startup processing function/procedure in this file as recommended by standard coding practise and FiC etc.
(As per WWMesgBrd forum article = Handling Application Startup Errors in web mode)
So unfortunately these direct Form and MessageBox calls from this initial program file are needed in
both LAN and WEB modules and so I have applied in part the suggested methodology for the MessageBox calls
to be retained in LAN mode as per instructions shown in the article above,
however, that still doesn't really deal with the missing visual queueing/prompting issue on the WEB calls
and only logging the issue to a text file is not sufficient for my purposes.

(1) How would you code for that situation?
- Thinking out aloud, maybe this is where jQUERY with Vbs type messagebox calls could be brought in.
- Another possible idea that comes to mind is to maybe create a blank Top-level form which contains either
(i) an embedded wMessageBox call within the Init() method than is triggered,
and so I can call this form instead which may become hidden when the Message box shows/is activated
or hides behind the Msgbox instead.
(ii) simulate a messagebox dialog by creating my own Form-based Msgbox with control objects applicable like OK/Cancel buttons etc

(2) As for Forms, how do I adapt these (Top-level) Form calls (DO sample.scx) from within this Mains program file ?
- I have looked through all the FiC pdf's provided onsite eg. FiC-How-to-wForm-en.pdf + FiC-How-to-azTuto3-en.pdf + FAA help + WWMsgBrd
All I can deduce from this is that (after I publish my app from within the FAA) I edit my app's xxxxServer.prg
and create a sub-class of the awProcess in the section demarcated by DEFINE CLASS esasProcess AS awProcess OF awServer.prg
eg.
-------------------------------------------
PROCEDURE myTopLevelForm
this.wFormStandardPage('myTopLevelForm.scx') && add params if necessary
EXTERNAL FORM myTopLevelForm.scx && instructs project manager to add form
--------------------------------------------

But how do I call this form in the actual Mains program file and how do I deal with any call back issues or return variables?

(i) this.wForm('myTopLevelForm.scx', .T.) && Modal form discarding user's choice
(ii) wFormMaster('myTopLevelForm.scx') && Modeless form
(iii) aVar = wForm('myTopLevelForm.scx', 'wFormCallBack') && Modal form keeping user's choice

- How come I can't use _SCREEN as my top-level form instead and call these other Mains program -based forms from there?
_SCREEN.wForm('myTopLevelForm.scx')

--------------------------------------------------------------------------------
My PC Setup = Win7 Prof (SP1) 64bit + VFP v9 + IIS 7.5 + FAA & FAS v2.10
My Skill level = GIS Analyst & App/DB Developer (only a few weeks into VFP and FiC)

Gravatar is a globally recognized avatar based on your email address. Re: How to adapt Top-level Form calls and MessageBox calls from a Mains Program file
  GLS
  Dré
  Oct 28, 2014 @ 11:59pm
Hi Dré

you can use :

* ===========================================
DEFINE CLASS xxxServer AS awServer OF awServer.prg
* ===========================================

...........................
........

uFormsLaunchAtStartup = 'MYFIRSTFORM.SCX'
&& {fr} Écrans de premier niveau à instancier au démarrage du serveur :
&& {fr} - 'form1,form2,...' lance ces formulaires
&& {fr} - .T. lance tous les formulaires inclus au projet
&& {fr} - vide n'en lance aucun
&& {fr} Renseignez cette propriété si vous utilisez ASP, ASPX, PHP, ou autre pour construire vos pages HTML,
&& {fr} au lieu d'une sous-classe de 'awProcess' (this.cawProcessClass)
&& {fr} Si vous utilisez une sous-classe de 'awProcess' (recommandé, voir ci-dessus), cette déclaration est inutile
&& {fr} car vous pouvez instancier les formulaires dynamiquement avec une méthode awProcess::wForm*()
&& {fr} Liste séparée par des virgules : *.scx, class, *.vcx
&& {fr} *.vcx : toutes les classes Form contenues dans le .vcx sont instanciées
&& {fr} > dans ce cas awAppConfig::cPrgPath est REQUIS
&& {fr} Voir un exemple d'implémentation en ASP : ..\Site\demoTest\Form.asp ou ..\Site\demoProd\Form.asp
&& {en} Master form(s) to be instantiated at server startup:
&& {en} - 'form1,form2,...' launches these forms
&& {en} - .T. launches all forms that can be found in project
&& {en} - empty() launches none
&& {en} Declare master forms if you use ASP, ASPX, PHP or any mean to build your HTML pages,
&& {en} rather than a sub-class of 'awProcess' (this.cawProcessClass)
&& {en} If you use a sub-class of 'awProcess' (recommended as explained above),
&& {en} you can instantiate forms just when needed by calling a awProcess::wForm*() method
&& {en} Coma-separated list: *.scx, class, *.vcx
&& {en} *.vcx: all form classes contained in the class library are instantiated;
&& {en} > in this case, awAppConfig::cPrgPath is REQUIRED
&& {en} See a sample ASP implementation: ..\Site\demoTest\Form.asp or ..\Site\demoProd\Form.asp


......................
..................

* ===========================================
ENDDEFINE && CLASS xxxServer
* ===========================================

to start an init form for you'r app xxx..

The process flow for operating a Web application / HTML / CSS / JS do not go like a FoxPro executable application.
You can not do without a change in your Foxpro sources to modify the behavior of the progress of your start process compatible with WEB mode.

You'll have to put their hands in the dough to change the initial settings VFP code of your application, will be made ​​once and for all at the launch of the Web application server.

This is a somewhat tedious but unavoidable work, what mistakes an application LAN mono-single-user session can not be adapted and used in multi-session and multi-user WEB mode.

Regards
Gilles
Hi guys,

I have a large (mains) program file that hasn't been properly normalised by the previous developers of this app.
ie. there is no startup processing function/procedure in this file as recommended by standard coding practise and FiC etc.
(As per WWMesgBrd forum article = Handling Application Startup Errors in web mode)
So unfortunately these direct Form and MessageBox calls from this initial program file are needed in
both LAN and WEB modules and so I have applied in part the suggested methodology for the MessageBox calls
to be retained in LAN mode as per instructions shown in the article above,
however, that still doesn't really deal with the missing visual queueing/prompting issue on the WEB calls
and only logging the issue to a text file is not sufficient for my purposes.

(1) How would you code for that situation?
- Thinking out aloud, maybe this is where jQUERY with Vbs type messagebox calls could be brought in.
- Another possible idea that comes to mind is to maybe create a blank Top-level form which contains either
(i) an embedded wMessageBox call within the Init() method than is triggered,
and so I can call this form instead which may become hidden when the Message box shows/is activated
or hides behind the Msgbox instead.
(ii) simulate a messagebox dialog by creating my own Form-based Msgbox with control objects applicable like OK/Cancel buttons etc

(2) As for Forms, how do I adapt these (Top-level) Form calls (DO sample.scx) from within this Mains program file ?
- I have looked through all the FiC pdf's provided onsite eg. FiC-How-to-wForm-en.pdf + FiC-How-to-azTuto3-en.pdf + FAA help + WWMsgBrd
All I can deduce from this is that (after I publish my app from within the FAA) I edit my app's xxxxServer.prg
and create a sub-class of the awProcess in the section demarcated by DEFINE CLASS esasProcess AS awProcess OF awServer.prg
eg.
-------------------------------------------
PROCEDURE myTopLevelForm
this.wFormStandardPage('myTopLevelForm.scx') && add params if necessary
EXTERNAL FORM myTopLevelForm.scx && instructs project manager to add form
--------------------------------------------

But how do I call this form in the actual Mains program file and how do I deal with any call back issues or return variables?

(i) this.wForm('myTopLevelForm.scx', .T.) && Modal form discarding user's choice
(ii) wFormMaster('myTopLevelForm.scx') && Modeless form
(iii) aVar = wForm('myTopLevelForm.scx', 'wFormCallBack') && Modal form keeping user's choice

- How come I can't use _SCREEN as my top-level form instead and call these other Mains program -based forms from there?
_SCREEN.wForm('myTopLevelForm.scx')

Gravatar is a globally recognized avatar based on your email address. Re: How to adapt Top-level Form calls and MessageBox calls from a Mains Program file
  n/a
  LLS
  Oct 29, 2014 @ 01:06am
Thanx LLS, I am aware of this method of instantiation, however I'm not using ASP, ASPX, PHP or any other external means to build my HTML pages,
rather I'm following the suggested route of sub-classing the 'awProcess' , so then I can instantiate any of these forms when I want to in my Mains program code
via the wForm() method. Now this is where I need help to exactly write that instruction syntactically:

Also, since I have multiple Top-level forms and Messageboxes interdispersed throughout the Mains Program file on the same level of hierarchical calls,
eliminating the option of springboarding off one particular Splashscreen or Menu called form as a lot of other apps do. My code for example is:

Declarations
code...
MessageBox call
more code ...
Do Top-level-form1 && Checking routines
more code...
Do Top-level-form2 -> which springboards the Tree with further Child Forms calls
more code ...
etc.


Hi Dré

you can use :

* ===========================================
DEFINE CLASS xxxServer AS awServer OF awServer.prg
* ===========================================

...........................
........

uFormsLaunchAtStartup = 'MYFIRSTFORM.SCX'
&& {fr} Écrans de premier niveau à instancier au démarrage du serveur :
&& {fr} - 'form1,form2,...' lance ces formulaires
&& {fr} - .T. lance tous les formulaires inclus au projet
&& {fr} - vide n'en lance aucun
&& {fr} Renseignez cette propriété si vous utilisez ASP, ASPX, PHP, ou autre pour construire vos pages HTML,
&& {fr} au lieu d'une sous-classe de 'awProcess' (this.cawProcessClass)
&& {fr} Si vous utilisez une sous-classe de 'awProcess' (recommandé, voir ci-dessus), cette déclaration est inutile
&& {fr} car vous pouvez instancier les formulaires dynamiquement avec une méthode awProcess::wForm*()
&& {fr} Liste séparée par des virgules : *.scx, class, *.vcx
&& {fr} *.vcx : toutes les classes Form contenues dans le .vcx sont instanciées
&& {fr} > dans ce cas awAppConfig::cPrgPath est REQUIS
&& {fr} Voir un exemple d'implémentation en ASP : ..\Site\demoTest\Form.asp ou ..\Site\demoProd\Form.asp
&& {en} Master form(s) to be instantiated at server startup:
&& {en} - 'form1,form2,...' launches these forms
&& {en} - .T. launches all forms that can be found in project
&& {en} - empty() launches none
&& {en} Declare master forms if you use ASP, ASPX, PHP or any mean to build your HTML pages,
&& {en} rather than a sub-class of 'awProcess' (this.cawProcessClass)
&& {en} If you use a sub-class of 'awProcess' (recommended as explained above),
&& {en} you can instantiate forms just when needed by calling a awProcess::wForm*() method
&& {en} Coma-separated list: *.scx, class, *.vcx
&& {en} *.vcx: all form classes contained in the class library are instantiated;
&& {en} > in this case, awAppConfig::cPrgPath is REQUIRED
&& {en} See a sample ASP implementation: ..\Site\demoTest\Form.asp or ..\Site\demoProd\Form.asp


......................
..................

* ===========================================
ENDDEFINE && CLASS xxxServer
* ===========================================

to start an init form for you'r app xxx..

The process flow for operating a Web application / HTML / CSS / JS do not go like a FoxPro executable application.
You can not do without a change in your Foxpro sources to modify the behavior of the progress of your start process compatible with WEB mode.

You'll have to put their hands in the dough to change the initial settings VFP code of your application, will be made ​​once and for all at the launch of the Web application server.

This is a somewhat tedious but unavoidable work, what mistakes an application LAN mono-single-user session can not be adapted and used in multi-session and multi-user WEB mode.

Regards
Gilles
Hi guys,

I have a large (mains) program file that hasn't been properly normalised by the previous developers of this app.
ie. there is no startup processing function/procedure in this file as recommended by standard coding practise and FiC etc.
(As per WWMesgBrd forum article = Handling Application Startup Errors in web mode)
So unfortunately these direct Form and MessageBox calls from this initial program file are needed in
both LAN and WEB modules and so I have applied in part the suggested methodology for the MessageBox calls
to be retained in LAN mode as per instructions shown in the article above,
however, that still doesn't really deal with the missing visual queueing/prompting issue on the WEB calls
and only logging the issue to a text file is not sufficient for my purposes.

(1) How would you code for that situation?
- Thinking out aloud, maybe this is where jQUERY with Vbs type messagebox calls could be brought in.
- Another possible idea that comes to mind is to maybe create a blank Top-level form which contains either
(i) an embedded wMessageBox call within the Init() method than is triggered,
and so I can call this form instead which may become hidden when the Message box shows/is activated
or hides behind the Msgbox instead.
(ii) simulate a messagebox dialog by creating my own Form-based Msgbox with control objects applicable like OK/Cancel buttons etc

(2) As for Forms, how do I adapt these (Top-level) Form calls (DO sample.scx) from within this Mains program file ?
- I have looked through all the FiC pdf's provided onsite eg. FiC-How-to-wForm-en.pdf + FiC-How-to-azTuto3-en.pdf + FAA help + WWMsgBrd
All I can deduce from this is that (after I publish my app from within the FAA) I edit my app's xxxxServer.prg
and create a sub-class of the awProcess in the section demarcated by DEFINE CLASS esasProcess AS awProcess OF awServer.prg
eg.
-------------------------------------------
PROCEDURE myTopLevelForm
this.wFormStandardPage('myTopLevelForm.scx') && add params if necessary
EXTERNAL FORM myTopLevelForm.scx && instructs project manager to add form
--------------------------------------------

But how do I call this form in the actual Mains program file and how do I deal with any call back issues or return variables?

(i) this.wForm('myTopLevelForm.scx', .T.) && Modal form discarding user's choice
(ii) wFormMaster('myTopLevelForm.scx') && Modeless form
(iii) aVar = wForm('myTopLevelForm.scx', 'wFormCallBack') && Modal form keeping user's choice

- How come I can't use _SCREEN as my top-level form instead and call these other Mains program -based forms from there?
_SCREEN.wForm('myTopLevelForm.scx')



--------------------------------------------------------------------------------
My PC Setup = Win7 Prof (SP1) 64bit + VFP v9 + IIS 7.5 + FAA & FAS v2.10
My Skill level = GIS Analyst & App/DB Developer (only a few weeks into VFP and FiC)

Gravatar is a globally recognized avatar based on your email address. Re: How to adapt Top-level Form calls and MessageBox calls from a Mains Program file
  FoxInCloud Support - Thierry N.
  Dré
  Oct 29, 2014 @ 02:24am
Hi Dré,

(1) How would you code for that situation?

There is no, and will never be any user attendance at server startup;
the reason for that is universal - not specific to FoxInCloud: a Web Application server is dedicated to multiple users, a Desktop Application to a single user.

This is the major, if not the only mental shift you need to move form a desktop paradigm to a web paradigm - and again it's generic for any Web Application, nothing specific to FoxInCloud

(2) As for Forms, how do I adapt these (Top-level) Form calls (DO sample.scx) from within this Mains program file ?

The solution depends what kind of decision your application expects from the user ... let me throw some assumptions as examples:
1/ application-wide operations such as data maintenance (eg 'do you want to purge deleted records'): implement some xxxAppConfig switches to decide whether to execute these maintenance operations or not at server startup (provided server can gain exclusive access to the data)
2/ user-specific settings like login - implement in your Web App home page index.xxx and, as explained in the doc, redirect index.htm to index.xxx

could you just throw a couple of examples of questions asked to the user during the application startup?

How come I can't use _SCREEN as my top-level form instead and call these other Mains program -based forms from there?
_SCREEN.wForm('myTopLevelForm.scx')

For at least 2 reasons:
- you can add properties to _SCREEN, not methods (eg wForm())
- _SCREEN is just a 'standard' base form supplied by VFP - you can do exactly the same with any other custom form (hence the concept of 'top-level form')

In Web mode, _SCREEN can be replaced by the page produced by index.xxx
that's how FICtuto works: http://foxincloud.com/tutotest/ (not really polished, just meant to show some basic coding and adaptation stuff with colorized code samples): all forms open within the FICtuto start page (index.tuto)

I hope this can help you ...


Hi guys,

I have a large (mains) program file that hasn't been properly normalised by the previous developers of this app.
ie. there is no startup processing function/procedure in this file as recommended by standard coding practise and FiC etc.
(As per WWMesgBrd forum article = Handling Application Startup Errors in web mode)
So unfortunately these direct Form and MessageBox calls from this initial program file are needed in
both LAN and WEB modules and so I have applied in part the suggested methodology for the MessageBox calls
to be retained in LAN mode as per instructions shown in the article above,
however, that still doesn't really deal with the missing visual queueing/prompting issue on the WEB calls
and only logging the issue to a text file is not sufficient for my purposes.

(1) How would you code for that situation?
- Thinking out aloud, maybe this is where jQUERY with Vbs type messagebox calls could be brought in.
- Another possible idea that comes to mind is to maybe create a blank Top-level form which contains either
(i) an embedded wMessageBox call within the Init() method than is triggered,
and so I can call this form instead which may become hidden when the Message box shows/is activated
or hides behind the Msgbox instead.
(ii) simulate a messagebox dialog by creating my own Form-based Msgbox with control objects applicable like OK/Cancel buttons etc

(2) As for Forms, how do I adapt these (Top-level) Form calls (DO sample.scx) from within this Mains program file ?
- I have looked through all the FiC pdf's provided onsite eg. FiC-How-to-wForm-en.pdf + FiC-How-to-azTuto3-en.pdf + FAA help + WWMsgBrd
All I can deduce from this is that (after I publish my app from within the FAA) I edit my app's xxxxServer.prg
and create a sub-class of the awProcess in the section demarcated by DEFINE CLASS esasProcess AS awProcess OF awServer.prg
eg.
-------------------------------------------
PROCEDURE myTopLevelForm
this.wFormStandardPage('myTopLevelForm.scx') && add params if necessary
EXTERNAL FORM myTopLevelForm.scx && instructs project manager to add form
--------------------------------------------

But how do I call this form in the actual Mains program file and how do I deal with any call back issues or return variables?

(i) this.wForm('myTopLevelForm.scx', .T.) && Modal form discarding user's choice
(ii) wFormMaster('myTopLevelForm.scx') && Modeless form
(iii) aVar = wForm('myTopLevelForm.scx', 'wFormCallBack') && Modal form keeping user's choice

- How come I can't use _SCREEN as my top-level form instead and call these other Mains program -based forms from there?
_SCREEN.wForm('myTopLevelForm.scx')

Gravatar is a globally recognized avatar based on your email address. Re: How to adapt Top-level Form calls and MessageBox calls from a Mains Program file
  n/a
  Thierry Nivelet (FoxInCloud)
  Oct 30, 2014 @ 10:27pm
So basically Thierry, you saying that I should rewrite my mains program (which is a single user, single threaded & single instance app only)
to start with a Splash Screen Form or Login Form as the foundational entry point for all other launches of my code and forms.
Thereby fulfilling the FiC (Web) requirements of:

(a) not being able to call a wMessagebox from a non-form-based object or independent program/procedure (like Mains)
(b) not being able to call a wForm from a non-form-based object or independent program/procedure (like Mains)

and I would also have to build a custom HTML web page (index.xxx)?

(1) Since I'm new to VFP, is there a Login Form template that you could recommend I use?

(2) As requested here is the Process flow of my App's Main program:
Note: calls start sequentially and only later on branch out from the Main Menu Form Screen
(I need these earlier calls to wForms and wMessageboxes to be incorporated so the user knows what's happening and gets notified accordingly)

- (Declares section) Variables, libraries etc
- (Procedure -local) Load Display Options (+ Messageboxes which contains error info and exits the system)
- (Procedure -local) Check File Writing Permissions (+ Messageboxes which contains error info and exits the system)
- (Form - Toplevel) System Initialisation dialog = Basically a status dialog checking if this is a new Install of app or not
- (Procedure -external) Open System Control File based on licensing (+ Messageboxes which contains error info and exits the system)
- (Procedure -external) Generate and authenticate License with key (+ Messageboxes which contains error info and exits the system)
- (Form - Toplevel) Visual Title = SplashScreen
- (Form - Childlevel) Software Buy Offer
- (Form - Toplevel) Password
- (Form - Toplevel) System Indexing
- (Form - Toplevel) Main Screen = Centralised Menu Buttons (everything else is launched from here as a Child-level branch)
- (Form - Childlevel) Data Entry
- (Form - Childlevel) Administration ..etc

I hope this gives you a better understaing of what my app's needs are.
Cheers.


Hi Dré,

(1) How would you code for that situation?

There is no, and will never be any user attendance at server startup;
the reason for that is universal - not specific to FoxInCloud: a Web Application server is dedicated to multiple users, a Desktop Application to a single user.

This is the major, if not the only mental shift you need to move form a desktop paradigm to a web paradigm - and again it's generic for any Web Application, nothing specific to FoxInCloud

(2) As for Forms, how do I adapt these (Top-level) Form calls (DO sample.scx) from within this Mains program file ?

The solution depends what kind of decision your application expects from the user ... let me throw some assumptions as examples:
1/ application-wide operations such as data maintenance (eg 'do you want to purge deleted records'): implement some xxxAppConfig switches to decide whether to execute these maintenance operations or not at server startup (provided server can gain exclusive access to the data)
2/ user-specific settings like login - implement in your Web App home page index.xxx and, as explained in the doc, redirect index.htm to index.xxx

could you just throw a couple of examples of questions asked to the user during the application startup?

How come I can't use _SCREEN as my top-level form instead and call these other Mains program -based forms from there?
_SCREEN.wForm('myTopLevelForm.scx')

For at least 2 reasons:
- you can add properties to _SCREEN, not methods (eg wForm())
- _SCREEN is just a 'standard' base form supplied by VFP - you can do exactly the same with any other custom form (hence the concept of 'top-level form')

In Web mode, _SCREEN can be replaced by the page produced by index.xxx
that's how FICtuto works: http://foxincloud.com/tutotest/ (not really polished, just meant to show some basic coding and adaptation stuff with colorized code samples): all forms open within the FICtuto start page (index.tuto)

I hope this can help you ...


Hi guys,

I have a large (mains) program file that hasn't been properly normalised by the previous developers of this app.
ie. there is no startup processing function/procedure in this file as recommended by standard coding practise and FiC etc.
(As per WWMesgBrd forum article = Handling Application Startup Errors in web mode)
So unfortunately these direct Form and MessageBox calls from this initial program file are needed in
both LAN and WEB modules and so I have applied in part the suggested methodology for the MessageBox calls
to be retained in LAN mode as per instructions shown in the article above,
however, that still doesn't really deal with the missing visual queueing/prompting issue on the WEB calls
and only logging the issue to a text file is not sufficient for my purposes.

(1) How would you code for that situation?
- Thinking out aloud, maybe this is where jQUERY with Vbs type messagebox calls could be brought in.
- Another possible idea that comes to mind is to maybe create a blank Top-level form which contains either
(i) an embedded wMessageBox call within the Init() method than is triggered,
and so I can call this form instead which may become hidden when the Message box shows/is activated
or hides behind the Msgbox instead.
(ii) simulate a messagebox dialog by creating my own Form-based Msgbox with control objects applicable like OK/Cancel buttons etc

(2) As for Forms, how do I adapt these (Top-level) Form calls (DO sample.scx) from within this Mains program file ?
- I have looked through all the FiC pdf's provided onsite eg. FiC-How-to-wForm-en.pdf + FiC-How-to-azTuto3-en.pdf + FAA help + WWMsgBrd
All I can deduce from this is that (after I publish my app from within the FAA) I edit my app's xxxxServer.prg
and create a sub-class of the awProcess in the section demarcated by DEFINE CLASS esasProcess AS awProcess OF awServer.prg
eg.
-------------------------------------------
PROCEDURE myTopLevelForm
this.wFormStandardPage('myTopLevelForm.scx') && add params if necessary
EXTERNAL FORM myTopLevelForm.scx && instructs project manager to add form
--------------------------------------------

But how do I call this form in the actual Mains program file and how do I deal with any call back issues or return variables?

(i) this.wForm('myTopLevelForm.scx', .T.) && Modal form discarding user's choice
(ii) wFormMaster('myTopLevelForm.scx') && Modeless form
(iii) aVar = wForm('myTopLevelForm.scx', 'wFormCallBack') && Modal form keeping user's choice

- How come I can't use _SCREEN as my top-level form instead and call these other Mains program -based forms from there?
_SCREEN.wForm('myTopLevelForm.scx')


Gravatar is a globally recognized avatar based on your email address. Re: How to adapt Top-level Form calls and MessageBox calls from a Mains Program file
  GLS
  Dré
  Oct 31, 2014 @ 01:12am
Hello Dré,

First there are not specific requirements FoxInCloud but dictated by the operation 100% FULL WEB ..

It certainly takes an initial HTML page as in toutesles WEB applications in HTML / CSS.
FoxIncloud with:
- A single empty file called index.htm for example will be sufficient to be used as start page.
- To call for a procedure / function of a prg program, "Messagebox" you must use the specific command FoxInCloud wMessageBox ().
- To call for a procedure / function of a prg program, a form must be used in one of two specific commands FoxInCloud wForm () or wFormMaster ()
However, no method of treatment can be initiated in return for these commands. Only the methods belonging to the calling form these orders will be processed in return for these commands (THISFORM.wMessageBox () etc ..)

- (Declares section) Variables, libraries
- (Procedure -local) "Load Display Options" without messagebox and exit because a web application is alway running
- (Procedure -local)" Check File Writing Permissions" without messagebox and exit because a web application is alway running
- (Form - Toplevel) Visual Title = SplashScreen with Login and Password for connecting user automatically called by the xxxServer.prg and by IIS
- (Procedure -external, "Open System Control File") called by the "Toplevel Login/password user" form, "Open System Control File" based on licensing
- (Procedure -external, "Generate and authenticate License) called by the "open System Control File" , "Generate and authenticate License" with key
- (Form - Toplevel , "Main Screen") Called by a callback method of the "Toplevel Login/password user form", Main Screen = Centralised Menu Buttons (everything else is launched from here as a Child-level branch)
- (Form - Childlevel) Data Entry
- (Form - Childlevel) Administration ..etc
- On each form or on a principal menu you must add a procedure to logoff your user and return to the form "Visual Title = SplashScreen with Login and Password"

Regards
Gilles


So basically Thierry, you saying that I should rewrite my mains program (which is a single user & single threaded app only)
to start with a Splash Screen Form or Login Form as the foundational entry point for all other launches of my code and forms.
Thereby fulfilling the FiC (Web) requirements of:

(a) not being able to call a Messagebox from a non-form-based object or independent program/procedure (like Mains)
(b) not being able to call a Form from a non-form-based object or independent program/procedure (like Mains)

and I would also have to build a custom HTML web page (index.xxx)?

(1) Since I'm new to VFP, is there a Login Form template that you could recommend I use?

(2) As requested here is the Process flow of my App's Main program:
Note: calls start sequentially and only later on branch out from the Main Menu Form Screen
(I need these earlier calls to Forms and Messageboxes to be incorporated)

- (Declares section) Variables, libraries etc
- (Procedure -local) Load Display Options (+ Messageboxes which contains error info and exits the system)
- (Procedure -local) Check File Writing Permissions (+ Messageboxes which contains error info and exits the system)
- (Form - Toplevel) System Initialisation dialog = Basically a status dialog checking if this is a new Install of app or not
- (Procedure -external) Open System Control File based on licensing (+ Messageboxes which contains error info and exits the system)
- (Procedure -external) Generate and authenticate License with key (+ Messageboxes which contains error info and exits the system)
- (Form - Toplevel) Visual Title = SplashScreen
- (Form - Childlevel) Software Buy Offer
- (Form - Toplevel) Password
- (Form - Toplevel) System Indexing
- (Form - Toplevel) Main Screen = Centralised Menu Buttons (everything else is launched from here as a Child-level branch)
- (Form - Childlevel) Data Entry
- (Form - Childlevel) Administration ..etc

I hope this gives you a better understaing of what my app's needs are.
Cheers.


Hi Dré,

(1) How would you code for that situation?

There is no, and will never be any user attendance at server startup;
the reason for that is universal - not specific to FoxInCloud: a Web Application server is dedicated to multiple users, a Desktop Application to a single user.

This is the major, if not the only mental shift you need to move form a desktop paradigm to a web paradigm - and again it's generic for any Web Application, nothing specific to FoxInCloud

(2) As for Forms, how do I adapt these (Top-level) Form calls (DO sample.scx) from within this Mains program file ?

The solution depends what kind of decision your application expects from the user ... let me throw some assumptions as examples:
1/ application-wide operations such as data maintenance (eg 'do you want to purge deleted records'): implement some xxxAppConfig switches to decide whether to execute these maintenance operations or not at server startup (provided server can gain exclusive access to the data)
2/ user-specific settings like login - implement in your Web App home page index.xxx and, as explained in the doc, redirect index.htm to index.xxx

could you just throw a couple of examples of questions asked to the user during the application startup?

How come I can't use _SCREEN as my top-level form instead and call these other Mains program -based forms from there?
_SCREEN.wForm('myTopLevelForm.scx')

For at least 2 reasons:
- you can add properties to _SCREEN, not methods (eg wForm())
- _SCREEN is just a 'standard' base form supplied by VFP - you can do exactly the same with any other custom form (hence the concept of 'top-level form')

In Web mode, _SCREEN can be replaced by the page produced by index.xxx
that's how FICtuto works: http://foxincloud.com/tutotest/ (not really polished, just meant to show some basic coding and adaptation stuff with colorized code samples): all forms open within the FICtuto start page (index.tuto)

I hope this can help you ...


Hi guys,

I have a large (mains) program file that hasn't been properly normalised by the previous developers of this app.
ie. there is no startup processing function/procedure in this file as recommended by standard coding practise and FiC etc.
(As per WWMesgBrd forum article = Handling Application Startup Errors in web mode)
So unfortunately these direct Form and MessageBox calls from this initial program file are needed in
both LAN and WEB modules and so I have applied in part the suggested methodology for the MessageBox calls
to be retained in LAN mode as per instructions shown in the article above,
however, that still doesn't really deal with the missing visual queueing/prompting issue on the WEB calls
and only logging the issue to a text file is not sufficient for my purposes.

(1) How would you code for that situation?
- Thinking out aloud, maybe this is where jQUERY with Vbs type messagebox calls could be brought in.
- Another possible idea that comes to mind is to maybe create a blank Top-level form which contains either
(i) an embedded wMessageBox call within the Init() method than is triggered,
and so I can call this form instead which may become hidden when the Message box shows/is activated
or hides behind the Msgbox instead.
(ii) simulate a messagebox dialog by creating my own Form-based Msgbox with control objects applicable like OK/Cancel buttons etc

(2) As for Forms, how do I adapt these (Top-level) Form calls (DO sample.scx) from within this Mains program file ?
- I have looked through all the FiC pdf's provided onsite eg. FiC-How-to-wForm-en.pdf + FiC-How-to-azTuto3-en.pdf + FAA help + WWMsgBrd
All I can deduce from this is that (after I publish my app from within the FAA) I edit my app's xxxxServer.prg
and create a sub-class of the awProcess in the section demarcated by DEFINE CLASS esasProcess AS awProcess OF awServer.prg
eg.
-------------------------------------------
PROCEDURE myTopLevelForm
this.wFormStandardPage('myTopLevelForm.scx') && add params if necessary
EXTERNAL FORM myTopLevelForm.scx && instructs project manager to add form
--------------------------------------------

But how do I call this form in the actual Mains program file and how do I deal with any call back issues or return variables?

(i) this.wForm('myTopLevelForm.scx', .T.) && Modal form discarding user's choice
(ii) wFormMaster('myTopLevelForm.scx') && Modeless form
(iii) aVar = wForm('myTopLevelForm.scx', 'wFormCallBack') && Modal form keeping user's choice

- How come I can't use _SCREEN as my top-level form instead and call these other Mains program -based forms from there?
_SCREEN.wForm('myTopLevelForm.scx')



Gravatar is a globally recognized avatar based on your email address. Re: How to adapt Top-level Form calls and MessageBox calls from a Mains Program file
  FoxInCloud Support - Thierry N.
  Dré
  Oct 31, 2014 @ 04:13am
So basically Thierry, you saying that I should rewrite my mains program (which is a single user, single threaded & single instance app only)

http://foxincloud.com/how-to.php?&howto=azTuto3 (p. 21) covers this need - usually we recommend to do this app startup adaptation as a 'last round of adaptations' - As you're evaluating the workload, I understand you need a clear idea of what's required.

to start with a Splash Screen Form or Login Form as the foundational entry point for all other launches of my code and forms.
You can have a login form with a splash image on top of it which fades or slides up or (or whatever animation you like)

Here is a sample (click image or link below):

http://foxincloud.com/SampleIndex.php
(to be included in the next release, in [path to VFP9]\Tools\AB\AW\App\Form\)

We've added in xxxProcess:

* ------------------
PROCEDURE SampleIndex && for demo purpose
return this.wFormStandardPage( "SampleIndex.scx")
external form SampleIndex && makes sure VFP project manager includes this form

Form's code is pretty simple:

**************************************************
*-- Form: sampleindex (c:\program files\vfp9\tools\ab\aw\app\form\sampleindex.scx)
*-- ParentClass: awfrm (c:\program files\vfp9\tools\ab\aw.vcx) && to be changed to xxx.vcx
*-- BaseClass: form
*-- Time Stamp: 10/31/14 11:15:10 AM
*

DEFINE CLASS sampleindex AS awfrm of aw.vcx && to be changed to xxx.vcx
Height = 366
Width = 522
DoCreate = .T.
AutoCenter = .T.
BorderStyle = 0
Caption = "Welcome to my super App!"
TitleBar = 0
BackColor = RGB(255,255,255)
wlAnonymousAllowed = .T. && important - the other forms should keep the default .F. to make sure only logged-in user can see them
Name = "SAMPLEINDEX"
waitpic.Height = 20
waitpic.Width = 20
waitpic.ZOrderSet = 0
waitpic.Name = "waitpic"


ADD OBJECT lbltitle AS awlbl of aw.vcx; && to be changed to xxx.vcx
WITH ;
FontSize = 14, ;
Alignment = 2, ;
BackStyle = 0, ;
Caption = "Welcome to my super Web Application!", ;
Height = 36, ;
Left = 41, ;
Top = 24, ;
Width = 456, ;
ZOrderSet = 1, ;
Name = "lblTitle"


ADD OBJECT txtlogin AS awtxt of aw.vcx; && to be changed to xxx.vcx
WITH ;
Height = 21, ;
Left = 250, ;
Top = 95, ;
Width = 110, ;
ZOrderSet = 2, ;
wcpropsave = "backcolor", ;
Name = "txtLogin"


ADD OBJECT txtpass AS awtxt of aw.vcx; && to be changed to xxx.vcx
WITH ;
Height = 21, ;
Left = 250, ;
Top = 143, ;
Width = 110, ;
ZOrderSet = 3, ;
wcpropsave = "backcolor", ;
Name = "txtPass"


ADD OBJECT lbllogin AS awlbl of aw.vcx; && to be changed to xxx.vcx
WITH ;
BackStyle = 0, ;
Caption = "Login", ;
Height = 17, ;
Left = 165, ;
Top = 99, ;
Width = 77, ;
ZOrderSet = 4, ;
Name = "lblLogin"


ADD OBJECT lblpass AS awlbl of aw.vcx; && to be changed to xxx.vcx
WITH ;
BackStyle = 0, ;
Caption = "Password", ;
Height = 17, ;
Left = 165, ;
Top = 147, ;
Width = 77, ;
ZOrderSet = 5, ;
Name = "lblPass"


ADD OBJECT imgapp AS awimg WITH ;
Picture = "..\site\images\fic-logo-js.png", ;
Stretch = 1, ;
Height = 124, ;
Left = 128, ;
Top = 204, ;
Width = 265, ;
ZOrderSet = 6, ;
Name = "imgApp"


ADD OBJECT imgsplash AS awimg of aw.vcx; && to be changed to xxx.vcx
WITH ;
Picture = "..\site\images\foxincloud-panel.jpg", ;
Stretch = 1, ;
Height = 403, ;
Left = -10, ;
Top = -15, ;
Width = 548, ;
ZOrderSet = 7, ;
Name = "imgSplash"

PROCEDURE load
use users
return dodefault()

PROCEDURE txtpass.Valid
do case

case thisform.wlHTMLgen
return

case .T.;
and Seek(Trim(this.Parent.txtLogin.Value) + m.this.Value, 'users', 'logpass'); && assuming users has: index on padr(trim(login) + pass, 100) tag logpass candidate
and thisForm.wUserLogIn(users.ID); && assuming users has: index on ID tag ID primary
and thisForm.wFormMaster('menu.scx', users.ID) && opens menu.scx in a full page && menu.scx can have a set of buttons with .click() doing thisForm.wForm(‘someForm.scx’)

case !Seek(this.Parent.txtLogin.Value, 'users', 'login') && assuming users has: index on login tag login
this.Parent.txtLogin.backColor = Rgb(255,0,0) && red
this.backColor = Rgb(255,255,255) && white

otherwise
this.Parent.txtLogin.backColor = Rgb(255,255,255) && white
this.backColor = Rgb(255,0,0) && red

endcase
ENDPROC


PROCEDURE imgsplash.wchtmlgen
LPARAMETERS toHTMLgen AS awHTMLgen OF awHTML.prg, tlInnerHTML && {en} awHTMLgen instance {fr} instance de awHTMLgen && [.F.] {en} render container's inner HTML {fr} Rendre l'intérieur du conteneur

local lcJS as String

&& Using Prototype & Scriptaculous:
&& see <<a href="http://madrobby.github.io/scriptaculous/effect-fade/" target="top" >>http://madrobby.github.io/scriptaculous/effect-fade/<</a>> for options and other effects
&& default effect duration: 1 s

lcJS = [$('<<m.this.wcID>>').fade();] && P1 - this image fades away right after form displays (default effect duration)
lcJS = [$('<<m.this.wcID>>').fade({duration: 1.2});] && P2 - this image fades away right after form displays (effect duration: 1.2 s)
lcJS = [Effect.Fade.delay(2, $('<<m.this.wcID>>'));] && P3 - same as (P1) above with a 2 s. delay before effect starts
lcJS = [Effect.Fade.delay(2, $('<<m.this.wcID>>'), {duration: 1.2});] && P4 - same as (P2) above with a 2 s. delay before effect starts

&& Using jQuery:
&& see <<a href="http://api.jquery.com/fadeout/" target="top" >>http://api.jquery.com/fadeout/<</a>>
&& default effect duration: 400 ms

lcJS = [jQuery('#<<m.this.wcID>>').fadeOut();] && J1 - this image fades away right after form displays (default effect duration)
lcJS = [jQuery('#<<m.this.wcID>>').fadeOut(1200);] && J2 - this image fades away right after form displays (effect duration: 1.2 s)
lcJS = [jQuery('#<<m.this.wcID>>').delay(2000).fadeOut();] && J3 - same as (J1) above with a 2 s. delay before effect starts
lcJS = [jQuery('#<<m.this.wcID>>').delay(2000).fadeOut(1200);] && J4 - same as (J2) above with a 2 s. delay before effect starts

&& COPY & PASTE HERE THE VARIATION YOU WANT TO TEST
lcJS = [Effect.Fade.delay(2, $('<<m.this.wcID>>'), {duration: 1.2});] && P4 - same as (P2) above with a 2 s. delay before effect starts

* Add to Form's JavaScript
m.toHTMLgen.cScriptJSadd(Textmerge(m.lcJS))
ENDPROC


ENDDEFINE && sampleindex
**************************************************

Thereby fulfilling the FiC (Web) requirements of:
(a) not being able to call a wMessagebox from a non-form-based object or independent program/procedure (like Mains)
(b) not being able to call a wForm from a non-form-based object or independent program/procedure (like Mains)

As GLS and I mentioned, this is a Web App requirement;
In fact you need to mentally isolate in your main program:
(1) what code sets the application environment -> goes to xxxSets.Init()
(2) what code sets the user environment -> goes to main.prg for desktop mode, Index.xxx (and the derived forms) for Web mode

and I would also have to build a custom HTML web page (index.xxx)?
(1) Since I'm new to VFP, is there a Login Form template that you could recommend I use?

Please see the above sample

(2) As requested here is the Process flow of my App's Main program:
Note: calls start sequentially and only later on branch out from the Main Menu Form Screen
(I need these earlier calls to wForms and wMessageboxes to be incorporated so the user knows what's happening and gets notified accordingly)
- (Declares section) Variables, libraries etc
- (Procedure -local) Load Display Options (+ Messageboxes which contains error info and exits the system)
- (Procedure -local) Check File Writing Permissions (+ Messageboxes which contains error info and exits the system)
- (Form - Toplevel) System Initialisation dialog = Basically a status dialog checking if this is a new Install of app or not
- (Procedure -external) Open System Control File based on licensing (+ Messageboxes which contains error info and exits the system)
- (Procedure -external) Generate and authenticate License with key (+ Messageboxes which contains error info and exits the system)
- (Form - Toplevel) Visual Title = SplashScreen
- (Form - Childlevel) Software Buy Offer
- (Form - Toplevel) Password
- (Form - Toplevel) System Indexing
- (Form - Toplevel) Main Screen = Centralised Menu Buttons (everything else is launched from here as a Child-level branch)
- (Form - Childlevel) Data Entry
- (Form - Childlevel) Administration ..etc

What we recommend is to come up with a xxxSets application initialization class that the desktop and the web versions of your application can share; you'll come up with something like

Desktop version


LOCAL loEnv, nSec

* Load FoxInCloud shared resources
* -------------------------

do (Home(1) + '\Tools\AB\ab.prg')

* Set Application environment
* -------------------------

loEnv = newObject(‘‘xxxSets’, Addbs(JustPath(Sys(16))) + ‘xxxSets.prg’)

* Launch main form
* -------------------------

DO FORM Index
READ EVENTS

&& then you can have all your variations

Web version


Web mode probably don’t need the following:
- (Procedure -local) Check File Writing Permissions (+ Messageboxes which contains error info and exits the system)
- (Form - Toplevel) System Initialisation dialog = Basically a status dialog checking if this is a new Install of app or not
- (Procedure -external) Open System Control File based on licensing (+ Messageboxes which contains error info and exits the system)
- (Procedure -external) Generate and authenticate License with key (+ Messageboxes which contains error info and exits the system)

all the licensing and install stuff are irrelevant for a Web App.

All you might need is a test whether the # of licenses for this specific client is reached, with either a login denial or an email to let your commercial people sell an extra pack of licenses.

you might need
- (Procedure -local) Load Display Options (+ Messageboxes which contains error info and exits the system)
if this related to the user, like preferences

you can group
- (Form - Toplevel) Visual Title = SplashScreen
- (Form - Childlevel) Software Buy Offer
- (Form - Toplevel) Password
into a single form like the sample above

if login is successful you display
- (Form - Toplevel) Main Screen = Centralised Menu Buttons (everything else is launched from here as a Child-level branch)

as a master form holding a bunch of button opening the other forms:
- (Form - Childlevel) Data Entry
- (Form - Childlevel) Administration ..etc

as child forms using:

procedure click
if thisForm.wlHTMLgen
return
endif
thisForm.wForm(‘Data Entry.scx’) && or whatever

I hope this gives you a better understanding of what my app's needs are.

Very detailed and clear, thanks
Gravatar is a globally recognized avatar based on your email address. Re: How to adapt Top-level Form calls and MessageBox calls from a Mains Program file
  n/a
  Thierry Nivelet (FoxInCloud)
  Oct 31, 2014 @ 09:06am
Thank you so much for the extra info Thierry and LLS, your detailed explanations have definitely help clarify the adaption process a lot more.
Hopefully you can incorporate some of this info into the adaption tutorial guides for user's with complicated apps like myself.

Cheers.


So basically Thierry, you saying that I should rewrite my mains program (which is a single user, single threaded & single instance app only)

http://foxincloud.com/how-to.php?&howto=azTuto3 (p. 21) covers this need - usually we recommend to do this app startup adaptation as a 'last round of adaptations' - As you're evaluating the workload, I understand you need a clear idea of what's required.

to start with a Splash Screen Form or Login Form as the foundational entry point for all other launches of my code and forms.
You can have a login form with a splash image on top of it which fades or slides up or (or whatever animation you like)

Here is a sample (click image or link below):

http://foxincloud.com/SampleIndex.php
(to be included in the next release, in [path to VFP9]\Tools\AB\AW\App\Form\)

We've added in xxxProcess:

* ------------------
PROCEDURE SampleIndex && for demo purpose
return this.wFormStandardPage( "SampleIndex.scx")
external form SampleIndex && makes sure VFP project manager includes this form

Form's code is pretty simple:

**************************************************
*-- Form: sampleindex (c:\program files\vfp9\tools\ab\aw\app\form\sampleindex.scx)
*-- ParentClass: awfrm (c:\program files\vfp9\tools\ab\aw.vcx) && to be changed to xxx.vcx
*-- BaseClass: form
*-- Time Stamp: 10/31/14 11:15:10 AM
*

DEFINE CLASS sampleindex AS awfrm of aw.vcx && to be changed to xxx.vcx
Height = 366
Width = 522
DoCreate = .T.
AutoCenter = .T.
BorderStyle = 0
Caption = "Welcome to my super App!"
TitleBar = 0
BackColor = RGB(255,255,255)
wlAnonymousAllowed = .T. && important - the other forms should keep the default .F. to make sure only logged-in user can see them
Name = "SAMPLEINDEX"
waitpic.Height = 20
waitpic.Width = 20
waitpic.ZOrderSet = 0
waitpic.Name = "waitpic"


ADD OBJECT lbltitle AS awlbl of aw.vcx; && to be changed to xxx.vcx
WITH ;
FontSize = 14, ;
Alignment = 2, ;
BackStyle = 0, ;
Caption = "Welcome to my super Web Application!", ;
Height = 36, ;
Left = 41, ;
Top = 24, ;
Width = 456, ;
ZOrderSet = 1, ;
Name = "lblTitle"


ADD OBJECT txtlogin AS awtxt of aw.vcx; && to be changed to xxx.vcx
WITH ;
Height = 21, ;
Left = 250, ;
Top = 95, ;
Width = 110, ;
ZOrderSet = 2, ;
wcpropsave = "backcolor", ;
Name = "txtLogin"


ADD OBJECT txtpass AS awtxt of aw.vcx; && to be changed to xxx.vcx
WITH ;
Height = 21, ;
Left = 250, ;
Top = 143, ;
Width = 110, ;
ZOrderSet = 3, ;
wcpropsave = "backcolor", ;
Name = "txtPass"


ADD OBJECT lbllogin AS awlbl of aw.vcx; && to be changed to xxx.vcx
WITH ;
BackStyle = 0, ;
Caption = "Login", ;
Height = 17, ;
Left = 165, ;
Top = 99, ;
Width = 77, ;
ZOrderSet = 4, ;
Name = "lblLogin"


ADD OBJECT lblpass AS awlbl of aw.vcx; && to be changed to xxx.vcx
WITH ;
BackStyle = 0, ;
Caption = "Password", ;
Height = 17, ;
Left = 165, ;
Top = 147, ;
Width = 77, ;
ZOrderSet = 5, ;
Name = "lblPass"


ADD OBJECT imgapp AS awimg WITH ;
Picture = "..\site\images\fic-logo-js.png", ;
Stretch = 1, ;
Height = 124, ;
Left = 128, ;
Top = 204, ;
Width = 265, ;
ZOrderSet = 6, ;
Name = "imgApp"


ADD OBJECT imgsplash AS awimg of aw.vcx; && to be changed to xxx.vcx
WITH ;
Picture = "..\site\images\foxincloud-panel.jpg", ;
Stretch = 1, ;
Height = 403, ;
Left = -10, ;
Top = -15, ;
Width = 548, ;
ZOrderSet = 7, ;
Name = "imgSplash"

PROCEDURE load
use users
return dodefault()

PROCEDURE txtpass.Valid
do case

case thisform.wlHTMLgen
return

case .T.;
and Seek(Trim(this.Parent.txtLogin.Value) + m.this.Value, 'users', 'logpass'); && assuming users has: index on padr(trim(login) + pass, 100) tag logpass candidate
and thisForm.wUserLogIn(users.ID); && assuming users has: index on ID tag ID primary
and thisForm.wFormMaster('menu.scx', users.ID) && opens menu.scx in a full page && menu.scx can have a set of buttons with .click() doing thisForm.wForm(‘someForm.scx’)

case !Seek(this.Parent.txtLogin.Value, 'users', 'login') && assuming users has: index on login tag login
this.Parent.txtLogin.backColor = Rgb(255,0,0) && red
this.backColor = Rgb(255,255,255) && white

otherwise
this.Parent.txtLogin.backColor = Rgb(255,255,255) && white
this.backColor = Rgb(255,0,0) && red

endcase
ENDPROC


PROCEDURE imgsplash.wchtmlgen
LPARAMETERS toHTMLgen AS awHTMLgen OF awHTML.prg, tlInnerHTML && {en} awHTMLgen instance {fr} instance de awHTMLgen && [.F.] {en} render container's inner HTML {fr} Rendre l'intérieur du conteneur

local lcJS as String

&& Using Prototype & Scriptaculous:
&& see http://madrobby.github.io/scriptaculous/effect-fade/ for options and other effects
&& default effect duration: 1 s

lcJS = [$('').fade();] && P1 - this image fades away right after form displays (default effect duration)
lcJS = [$('').fade({duration: 1.2});] && P2 - this image fades away right after form displays (effect duration: 1.2 s)
lcJS = [Effect.Fade.delay(2, $(''));] && P3 - same as (P1) above with a 2 s. delay before effect starts
lcJS = [Effect.Fade.delay(2, $(''), {duration: 1.2});] && P4 - same as (P2) above with a 2 s. delay before effect starts

&& Using jQuery:
&& see http://api.jquery.com/fadeout/
&& default effect duration: 400 ms

lcJS = [jQuery('#').fadeOut();] && J1 - this image fades away right after form displays (default effect duration)
lcJS = [jQuery('#').fadeOut(1200);] && J2 - this image fades away right after form displays (effect duration: 1.2 s)
lcJS = [jQuery('#').delay(2000).fadeOut();] && J3 - same as (J1) above with a 2 s. delay before effect starts
lcJS = [jQuery('#').delay(2000).fadeOut(1200);] && J4 - same as (J2) above with a 2 s. delay before effect starts

&& COPY & PASTE HERE THE VARIATION YOU WANT TO TEST
lcJS = [Effect.Fade.delay(2, $(''), {duration: 1.2});] && P4 - same as (P2) above with a 2 s. delay before effect starts

* Add to Form's JavaScript
m.toHTMLgen.cScriptJSadd(Textmerge(m.lcJS))
ENDPROC


ENDDEFINE && sampleindex
**************************************************

Thereby fulfilling the FiC (Web) requirements of:
(a) not being able to call a wMessagebox from a non-form-based object or independent program/procedure (like Mains)
(b) not being able to call a wForm from a non-form-based object or independent program/procedure (like Mains)

As GLS and I mentioned, this is a Web App requirement;
In fact you need to mentally isolate in your main program:
(1) what code sets the application environment -> goes to xxxSets.Init()
(2) what code sets the user environment -> goes to main.prg for desktop mode, Index.xxx (and the derived forms) for Web mode

and I would also have to build a custom HTML web page (index.xxx)?
(1) Since I'm new to VFP, is there a Login Form template that you could recommend I use?

Please see the above sample

(2) As requested here is the Process flow of my App's Main program:
Note: calls start sequentially and only later on branch out from the Main Menu Form Screen
(I need these earlier calls to wForms and wMessageboxes to be incorporated so the user knows what's happening and gets notified accordingly)
- (Declares section) Variables, libraries etc
- (Procedure -local) Load Display Options (+ Messageboxes which contains error info and exits the system)
- (Procedure -local) Check File Writing Permissions (+ Messageboxes which contains error info and exits the system)
- (Form - Toplevel) System Initialisation dialog = Basically a status dialog checking if this is a new Install of app or not
- (Procedure -external) Open System Control File based on licensing (+ Messageboxes which contains error info and exits the system)
- (Procedure -external) Generate and authenticate License with key (+ Messageboxes which contains error info and exits the system)
- (Form - Toplevel) Visual Title = SplashScreen
- (Form - Childlevel) Software Buy Offer
- (Form - Toplevel) Password
- (Form - Toplevel) System Indexing
- (Form - Toplevel) Main Screen = Centralised Menu Buttons (everything else is launched from here as a Child-level branch)
- (Form - Childlevel) Data Entry
- (Form - Childlevel) Administration ..etc

What we recommend is to come up with a xxxSets application initialization class that the desktop and the web versions of your application can share; you'll come up with something like

Desktop version


LOCAL loEnv, nSec

* Load FoxInCloud shared resources
* -------------------------

do (Home(1) + '\Tools\AB\ab.prg')

* Set Application environment
* -------------------------

loEnv = newObject(‘‘xxxSets’, Addbs(JustPath(Sys(16))) + ‘xxxSets.prg’)

* Launch main form
* -------------------------

DO FORM Index
READ EVENTS

&& then you can have all your variations

Web version


Web mode probably don’t need the following:
- (Procedure -local) Check File Writing Permissions (+ Messageboxes which contains error info and exits the system)
- (Form - Toplevel) System Initialisation dialog = Basically a status dialog checking if this is a new Install of app or not
- (Procedure -external) Open System Control File based on licensing (+ Messageboxes which contains error info and exits the system)
- (Procedure -external) Generate and authenticate License with key (+ Messageboxes which contains error info and exits the system)

all the licensing and install stuff are irrelevant for a Web App.

All you might need is a test whether the # of licenses for this specific client is reached, with either a login denial or an email to let your commercial people sell an extra pack of licenses.

you might need
- (Procedure -local) Load Display Options (+ Messageboxes which contains error info and exits the system)
if this related to the user, like preferences

you can group
- (Form - Toplevel) Visual Title = SplashScreen
- (Form - Childlevel) Software Buy Offer
- (Form - Toplevel) Password
into a single form like the sample above

if login is successful you display
- (Form - Toplevel) Main Screen = Centralised Menu Buttons (everything else is launched from here as a Child-level branch)

as a master form holding a bunch of button opening the other forms:
- (Form - Childlevel) Data Entry
- (Form - Childlevel) Administration ..etc

as child forms using:

procedure click
if thisForm.wlHTMLgen
return
endif
thisForm.wForm(‘Data Entry.scx’) && or whatever

I hope this gives you a better understanding of what my app's needs are.

Very detailed and clear, thanks


--------------------------------------------------------------------------------
My PC Setup = Win7 Prof (SP1) 64bit + VFP v9 + IIS 7.5 + FAA & FAS v2.10
My Skill level = GIS Analyst & App/DB Developer (only a few weeks into VFP and FiC)

Gravatar is a globally recognized avatar based on your email address. Re: How to adapt Top-level Form calls and MessageBox calls from a Mains Program file
  FoxInCloud Support - Thierry N.
  Dré
  Oct 31, 2014 @ 09:26am
Sure, as we are building the detailed documentation on doc.foxincloud.com (*.pdf are more like an overview to understand the basic principles on some simple case), we'll include all the material we get from user support - and add extra samples in the distributed *.prg and *.?cx

I do appreciate the way you report issues, very helpful for us to build a response as detailed and pertinent.

A nice week-end,


Thank you so much for the extra info Thierry and LLS, your detailed explanations have definitely help clarify the adaption process a lot more.
Hopefully you can incorporate some of this info into the adaption tutorial guides for user's with complicated apps like myself.
Cheers.


-- thn (FoxInCloud)

© 1996-2024