Hi,

I have noticed this scenario a few times now and would like some reassurance please that this won't be a problem in the compiled COM server (web connection).

During a "project"/uncompiled session where I am debugging in VFP, I open a form in the browser and encounter an error in the code.
That's fine; I stop the web server, fix the problem and restart the web server (do XXXtest).

The server starts up, detects that the form is still open in the browser and attempts to open it - the problem is that there were several steps to get to that form (e.g. a child form, or in fact pretty much most forms because the user hasn't even gone through the login yet) and the form cannot just open by itself without other things set up beforehand, so the server produces a runtime error due to missing data, or missing objects or whatever else it needs and halts execution.
The server is now dead.

What is the solution to this scenario?
I am sure it will happen on a client site, sooner or later; it will do no good to simply say "always close your browser tab" because the client will forget.

Thanks
Paul

Hi Paul,

the server produces a runtime error due to missing data, or missing objects or whatever else

This scenario has been properly handled for years in all applications in production: as the server is totally stateless and user state is stored on disk, it works the same whether it has started a long time ago, or just started.
eg. if user acts on a child form just after startup, the server automatically:

• restores the application-wide elements such as: public variables, _screen.properties and so on,
• instantiates the target form and restores its state,
• if applicable, instantiates the 'parent' form holding the data session,
• executes the user action,
• etc.

The issue you have means that your application fails to save or generate some elements:

• missing data: you probably miss some alias(es) and/or public variables and/or _screen.properties and/or _VFP.properties
• missing objects: please note that the dynamic contents feature is meant to display variable contents (eg. list of users, time table), and should be tied to data and updated in a .refresh() method so that it executes in whatever context; other pieces of code should not depend on whether dynamic objects exist or not, or in a way that encompasses all possible situations; please provide additional use cases for more help.

Server halts execution

On a FoxInCloud server, apart from having a forgotten suspend, execution can only stop on a modal instruction requiring a response from the user, such as a non-adapted messagebox or a 'file open' dialog. In production mode (file-based exe or COM), this can't happen during a user request as FoxInCloud issues a Sys(2335, 0) that triggers an error whenever this situation occurs. It may only happen during the server startup sequence, unless you use the same instruction in your xxxSets.Init().

The wc.ini!Timeout provides an additional protection: if the VFP/wConnect/FoxInCloud server does not respond within the timeout indicated (seconds), wc.dll kills the COM object and reloads another fresh instance; example (excerpt from wcErrors.txt of http://foxincloud.com/):

2018-10-17 03:29:52:386   COM Server Timed out - Next line releases - 1413
2018-10-17 03:29:53:398   Forced Release of Server - 183
2018-10-17 03:29:55:406   Web Connection Request timed out. - /roadmap.php? - 0
2018-10-17 06:31:33:013   RPC Server Unavailable (Invoke): Attempting to Reload Server... - /images/check.php? - 0

Hi,

I understand what you are saying and if our application was designed with the web model in mind it would probably behave like that.
Unfortunately I don't think automatic recovery of the session will always be possible - and that is fine, as long as the server skips over errors and continues running.

Here is the example I am working through at the moment :

1. user logs in and opens a master form using wFormStandardPage()
2. a child form is opened with wform() - private data session
3. Valid of a textbox opens another child form - private data session
4. this child form has a problem and crashes (actually, VFP has a fatal error and an appcrash when running grid.wafterrowchange())

When the server is restarted I see that the latest child form is reopened, but the view for the grid is not opened and the grid has an error (curiously, if I later click in the textbox at the top of the form I see that the view is opened then).
Perhaps I could rearrange the code to make that work, but in any case the first child form (with the textbox and its Valid) has not been reopened so it doesn't matter if the latest child form works or not.
...and that is all fine, I would be amazed if all that chain of event calling was recovered next time; ideally the user will simply be returned to the login screen after the error.

VFP has a fatal error and an appcrash when running grid.wafterrowchange()

Never seen that… what code do you have in grid.wafterrowchange()?

the view for the grid is not opened and the grid has an error (curiously, if I later click in the textbox at the top of the form I see that the view is opened then).

The form running a private dataSession, it should be all good if the view is used() before the dodefault() at the end of form.load()

Perhaps I could rearrange the code to make that work, but in any case the first child form (with the textbox and its Valid) has not been reopened so it doesn't matter if the latest child form works or not.

should open whenever the last child form is modal and responds to textbox.wFormCallBack*()

...and that is all fine, I would be amazed if all that chain of event calling was recovered next time; ideally the user will simply be returned to the login screen after the error.

FoxInCloud Live Tutorial implements this: see http://foxincloud.com/tutotest/fileDisplay.tuto?tutoServer.prg, search DEFINE CLASS tutoAJAX as awAJAX of awServer.prg and cawAJAXClass = 'tutoAJAX'

I have no code in grid.wafterrowchange() and no code in VFP's BeforeRowChange() or AfterRowChange(). I am still testing...
I will look at the tutoAjax code.

Thanks.

Hi,

I am still experiencing problems with this scenario.

1. user logs in and opens a master form using wFormStandardPage()
2. a child form, form1, is opened with wform() - private data session
3. Valid of a textbox opens another child form, form2, with wform() - private data session
   3a. user clicks a row in the grid in form2 and the form is released
   3b. this should call a method on form1 via the wform() callback --- this never happens, error before this

Sometimes VFP has a fatal error and an appcrash when running grid.wafterrowchange().
If this does not happen then instead I get this error window in the browser : "HTTP protocol error : not found".
The error occurs here :

1. sfictestserver.processhit()
2. .SendReturnMessageFile()
3. lhFile=FCREATE(THIS.cTempMessageRetfile)
   =FCLOSE(lhFile) --> crash, the file does not exist

THIS.cTempMessageRetfile = "C:\Users\Public\WC_D543.RET" and I cannot see this file in the folder.
Curiously, if I run SendReturnMessageFile() a second time then it works - the file is created and closed.
(I have excluded this folder from anti-virus scanning and most of the time the files are created, so no permission problem).

Here is the full call stack :

Ideas?

Hi Paul,

If you can reproduce the error, a screen cast would help a lot (preferably with browser developer tools open).

As your observations seem to cover several error causes, here are miscellaneous points I can bring so far:

HTTP protocol error: not found

AJAX request to a non-extent URL, server responds with a 404 HTTP error;
knowing the URL may help

THIS.cTempMessageRetfile = "C:\Users\Public\WC_D543.RET"

With FoxInCloud standard name spacing, folder should be "C:\Users\Public\xxxTest\"

Sometimes VFP has a fatal error and an appcrash when running grid.wafterrowchange()

There is no obvious relation between a specific user event and an error; in other words, as all user events follow the same process in FoxInCloud, there's no reason a specific event should always raise a given error.
An idea is that one of your variables in grid.wafterrowchange() code conflicts with wConnect: because in wConnect code some variables are not declared local, you may use a variable that is in fact "inherited" from a wConnect method.