Hi,

I am witnessing really strange behaviour changes that I cannot explain.
.

Difference in FiC / WC IDE appearance, from yesterday to today!!!

1. Yesterday when I ran FiC in the VFP IDE (file mode), the IDE remained visible and the WC server form was visible inside the VFP window; request stats were being printed to _screen.
2. Today, the IDE is hidden and the WC form is visible outside the VFP IDE (e.g. ShowInDesktop = .T.). The WC form now has a "show desktop" button in its top right corner - I can click it to show the IDE, but request hits/stats are not printed to _screen. The IDE appears again once FiC / WC is exited via the exit button on the WC server window.

Why? I have not changed any code, except I did recompile wwserver.prg after I removed some debug code I had added.
Has WC auto-updated (this does not seem likely, file dates are old)?
.

Difference in page scaling between prototype and production projects.
There must be some difference in a setting somewhere - I am hoping you can point me in the right direction.

Scaling behaviour in prototype project :
--> Great!

Scaling behaviour (and appearance) in production project :
--> Not great!

It looks like the HTML is not being regenerated during the second pass (per user) of the form's Init, as the label caption in the second form ( "shopfloor @ 1002...") and the resizing of forms occur then.
I have tried debugging this, but I have not found where HTML changes are applied after the initial generation, I have only seen the initial HTML being set. Where should I look for this?

.

Two other strange things about the UI difference :

1. Yesterday the production login page did not have the correct height, but at least the style was the same as the prototype.
   Today, you can see that the style of the login page has changed as well (border, title bar etc) !
2. In the prototype project, first created early this year, the property BSlHTMLgen was present in xxxprod.prg.
   In the production project, created several weeks ago, the property BSlHTMLgen was not present - so the setting in xxxserver.prg would have been used instead, which is .null.
   The result was that pages were being displayed with bootstrap on, despite the fact that wBSlHTMLGen = .F. on all forms!!!!
   I had to add the property back into xxxprod.prg and set to .F. to turn off bootstrap (none of our forms look ok with bootstrap on, but that is another job...).

• Note : adding the property back into xxxprod.prg removes bootstrap when running in file mode - but - when running in COM mode bootstrap is still on !
  .

Also, I now get this new error when FiC exits (click the exit button in the WC server window) :
EDIT - probably related to the IDE being hidden (_screen.visible = .F.); if the properties are not set initially in cusBatchLog.Init (see below) then the Destroy will error :

* {fr} Déterminer si les sorties doivent être envoyées à l'écran
this.alConsole = (m.lnParms < 4 or lTrue(m.tlConsole));
	and inlist(_vfp.startmode, 0, 1, 4);
	and vartype(_screen) == 'O' ;
	and _screen.visible
if m.this.alConsole
	this.acScreenFont = _screen.fontname
	this.anScreenFontSize = _screen.fontsize

I have found the answer to the scaling problem (and only that problem, so far).

In my prototype project I had added this to the Init of every visual base class :

If wlWeb() && 4TFIC
    wcPropSaveEdit(this, FOXINCLOUD_NATIVEPROPERTYSAVELIST)
Endif

Basically, I added all of the native properties I ever change into wcpropsave.
In my production project I did not add that code, thinking that the latest version of FiC now handles the runtime changing of native properties. I see that it does not, so I have added that code into production as well.

Paul

the style was the same as the prototype.
Today, you can see that the style of the login page has changed as well (border, title bar etc) !

Your prototype probably uses Prototype.js and Prototype Window Class, which are both deprecated in favour of jQueryUI 'dialogs' or Bootstrap 'modals'.

adding the property back into xxxprod.prg removes bootstrap when running in file mode

You can simply change in xxxServer (shared by xxxTest and xxxProd)

but - when running in COM mode bootstrap is still on !

Are you sure your exe was properly rebuilt? (requires running VFP with admin privileges as it attempts to write the COM signature into the registry)

get this new error when FiC exits

Move 2 lines below if this.alConsole:

if m.this.alConsole

  * {en} Restore screen font
  _screen.fontname = this.acScreenFont
  _screen.fontsize = this.anScreenFontSize

thinking that the latest version of FiC now handles the runtime changing of native properties

To avoid saving native properties that never change during user actions, we prefer the developer to figure out what properties are worse saving.

Only custom properties are saved by default.

Ok, I will add that code.

You are right about prototype.js, I stopped using it and that explains the different style.

I will continue to check the COM server.

Any idea about the change in the VFP IDE, going from visible to invisible?
Is the "show desktop" button in the WC server window what everyone else sees too? I never saw that prior to yesterday...

Any idea about the change in the VFP IDE, going from visible to invisible?

I suggest you set a breakpoint when _screen.visible changes

Is the "show desktop" button in the WC server window what everyone else sees too? I never saw that prior to yesterday...

Should have .visible = .F. at design time.

Regarding bootstrap and COM mode - from debugging I can see that BSLHTMLGen is in fact .F.

However, the forms are seriously weird (which is why I thought bootstrap is on).
Here is the login page in COM mode : All forms are like this.
You can see the login page in File mode in the previous post, quite normal.

Could it be that the COM server cannot read a CSS file or something similar?
NTFS security seems fine and the IIS application pool is running as SYSTEM (COM is configured for pass-through).
Here are the files in the web site :

Do you know what might be happening?

Every issue involving the browser's display MUST be first debugged using the browser developer tools.

In this case, you probably have an issue with awDefaultAll.css: either it does not load or it's not properly generated.

FoxinCloud updates awDefaultAll.css when testing your app in development mode, however it might help to fully re-generate it once in a while: do xxxTest.css.prg

I have now confirmed that the forms only look ok when running xxxprod.prg in the VFP IDE.
In these other scenarios the forms are weird :

1. run xxxprod.exe in VFP IDE
2. run xxxprod.exe standalone
3. run xxxprod.exe with COM

I can see how it looks like the CSS is not being read or is not correct, but if that was true then running xxxprod.prg would have the same result as the other methods, as all scenarios use the same CSS file.
I speculate that something is missing from the project - perhaps when running the .prg the missing thing is found within the path, but when running the .exe (or COM) that thing is not being found.
Alternatively, something is included in the project that should not be.

I will email you my project, could you please take a look and see if anything looks wrong.

btw, I tried running xxxprod.css.prg but got lots of errors displayed in wait windows and it eventually has a fatal appcrash every time. That is a problem for another day...

Paul

Again, the problem is that awDefaultAll.css is not properly generated using xxx[Test|Prod].css.prg. If your project and exe build OK, there's nothing else to look at.

xxxTest.css.prg only processes forms that are included in the project; you can just exclude those that fail.

As a workaround, you can just copy the latest awDefaultAll_<sys(2015)>.css into awDefaultAll.css

Note: analyzing your project code is billable, do you have the professional services and support leaflet?

awDefaultAll_<sys(2015)>.css is tiny compared to awDefaultAll.css and I don't understand how running the code one way works with the CSS and another way does not work, with the same CSS.
Anyway, I will investigate the CSS further as you say.

I emailed you my project file, but you can just ignore it.
Please send me your billing details, I don't have a copy - I think I am at the end of the road and may need some remote assistance.

Thanks
Paul

In development mode, after generating additional HTML/CSS/JS, FoxinCloud writes a new awDefaultAll_<sys(2015)>.css (new name necessary for the browser to reload the CSS, otherwise it keeps the cached version) and updates CSS in awDefaultAll.css, except the class definitions.

This may be the reason why your display is weird.
Perhaps copying the class definitions (at the beginning of file) from awDefaultAll_<sys(2015)>.css to awDefaultAll.css can fix the issue.

Will send you the requested material by PM.

Update: having xxx[Test|Prod].css.prg running smoothly is necessary for the production server update routine (xxx[Test|Prod].update.prg) to work fine.

Thank you Thierry, your advice about the .css was right (of course) and fixed the problem temporarily for me.
I will revisit xxxprod.css.prg when I get the chance.

Last question from me this week...
the instructions here FiC deployment tutorial explain to copy the scripts into awscripts and then delete _source.
When I look at a page source in the browser I see references to .js in the _source folder :
Is there a step I should be taking to change those references?

Thanks
Paul

Is there a step I should be taking to change those references?

No, FoxinCloud adapts the pathes whether it runs in development or production mode.