Messages
Reply
Edit
Delete11:50 am
3R50PD570
| From: | Tuvia Vinitsky |
| To: | FoxInCloud support |
I am quite right. Using the prg means that the prg uses ftp to copy the new .exe file to the site update folder. Then it calls the wc.dll function that replaces the running .exe with the new .exe located in the designated update folder.
1. Copying the new .exe yourself is preferable to unattended ftp. Admittedly this is a preference.
2. There is no mechanism for copying the files needed for updates in addition to the exe.
3. The wc.dll function occasionally fails when a specific user or group of users is designated in the ini file (as opposed to ANY/ALL users). When this happens, you will receive no error and you will think the update worked. Rick Strahl has investigated this and has no solution. Granted it is not a common occurence, and more likely on w2003 servers, but it happens on ALL our servers and Rick cannot determine why. He has seen it himself only very rarely. So using the admin.asp page and verifying the .exe file update is the more prudent approach.
4. FiC removed the update option from the admin.asp page prior to distributing it.
I cannot understand why FiC is so insistent that updates be done via pg and not via the WWC interface -- to the point of removing that option from the admin page!
An option I understand -- but the insistance on only the prg and no other options is difficult to understand.
Our clients either use our form which verifies that the exe update was successful (the prg does not) or we uncomment the option in the admin.asp page.
All our sites in production have had tens of update using the standard, FoxInCloud-supplied xxx.update.prg.
This program does have a bunch of error checks and does exactly the same as the admin page through wwHTTP.
You are free to use whatever tool you prefer, please make sure that the information you assert about FoxInCloud are right, ask question in case of doubt.
I was out for a week and as I scan the messages I see the "company line", if you will, about using a .prg to upload the new .exe to a site. I have to disagree with this advice.
1) Copying the exe manually or ftp'ing it manually to the update folder offers more control and reliability.
2) More importantly, I do not recall us ever needing just the exe. There is xxx.css, changes to xxx.js, and any other auxiallary files needed.
It makes it sound over-simplified to just say "run a prg and update the exe." (There are also times when the WWWC auto-update fails!)
We wrote a control form that does all the updating necessary, including data structure changes, and then cmpares to make sure the files are correct.4
If you onmly use the exe auto-update feature, better to uxe it from the admin.asp page, which will better display any errors.
In dev mode (IDE), you stop the server for any code change (differs from wConnect's xxxProcess.prg that you can modify while server is running; as FAS instantiates forms, you can't modify forms' source code without stopping the server).
In production, when your changes are done, you just run a simple program to upload the new .exe and swap production server .exe - stops server for about 10 seconds - when completed users resume their work without disruption; they often don't realize an update occurred.
I have no need to work with "copied" code, so I think I will stick with working with the source files only.
Question;
can I make a change to a form without stopping my clients?
I have not been able to change a form without stopping and restarting the web server.
exit the server then
do ....prod.prg with .t.
Copy mode is for test only - you should not modify copied code for real, just for test (on FAA, the help button near source/copy explains that).
If you modify Copied code, it can be replaced at any time by source code
If you modify Source code, you need to copy it again using FAA - by default, FAA detects differences and copies what has changed
I think my issues are more basic than you might think.
Let me give you a scenario.
I have my test project up and running. It has one form one table. I need to add a field to my table and a textbox to my form.
My test project resides on my desktop in a folder.
There is also a test project located on my root directory that FIC created during the FAA process.
Do I open the test project on my desktop and modify the form from there?
If I open the test project from my root drive, there are no forms included in the project, so do I modify the form directly, or go back to my desktop?
After I make my modifications, what are my options for making my changes active.
I am just getting started, so I am learning the rudiments and trying to think through the processes i will be going through in the future.
Thanks, Steve
Hi Steve
Two mode of change in HTML:
1) Each change on a VFP form need regenerating the awdefaultall.css. If you don't make that HTML page does not reflect the change. (To make that you under FIC/VFP run the xxxTest.prg with .T. to regenerate the CSS)
2) If you want to have different permanent look of an object on the HTML page than the HTML object look generate by FIC, you must change the CSS style of the object into the xxx.CSS file. Because the CSS is load after awDefaultAll.css, you will see on the HTML the styles that are include in the xxx.CSS.
Regards
Regarding; if you need to change aspect of your form (most probably), you can implement your CSS 'extensions' in xxx.css, based on the classes and ids you'll find in awDefault*.css.
can you go into more detail. For instance if I want to make changes to one of my forms in my project. Do I need to analyze and adapt again? or do I just publish.
For example, right now, If I change one of my forms, I am running adapt/analyze/publish then adding the Set path to my xxxsets.prg program so that it can find my forms.
Thanks, steve
if you need to change aspect of your form (most probably), you can implement your CSS 'extensions' in xxx.css, based on the classes and ids you'll find in awDefault*.css.
if you want to process some event by javascript, see inherited event code.
if you really need some specific HTML, you can implement it in *.wcHTMLgen(), at object or class level.
this.wcHTML = 'HTML you need'
documentation is mainly in FAA and code inherited from aw.vcx!*
The button also had the code set path to .....additive in it.
I noticed the FAA recommended moving that code. Since It was already in my sets.prg I just removed it and it started working. So it was just a path issue.
So for LAN mode I am keeping a main.prg for my app and for web mode, I just remove that program before FAA.
Thanks for the help, I will try your other suggestions soon regarding the studio.
I have a development question. Once I get the foxpro web portion functioning properly and I want to modify the HTML of the web pages, will I have to save separate versions of my changes.
For instance If I re run FAA won't all my HTML changes get overwritten?
Can I make modifications without stopping and restarting the web server/Studio. Right now if I try to make changes, I get an unable to access message.
Is there some more in depth documentation I need to read to catch up on these concepts?
Steve
did you adapt form1.scx?
what code do you have in form1.cmd.Click()?
in xxxServer.prg!xxxProcess, you should have:
procedure form1
this.wFormStandardPage('form1.scx') && not 'form1_scx'
I must be missing some key concept here. I am just getting started with FIC and I am trying to put together a demo for my boss so that I can show him what I could do with FIC in our environment.
I created a basic form with two buttons.
Each button is intended to launch another form.
The code in the button is just a simple DO FORM 'FORM2.scx'
it works fine in LAN mode. But when I try to press the button in web mode, nothing happens.
Also after I launch the main form a couple times I begin to get his error;
/!\ Site 'FoxInCloud App' - Elizprocess.wformstandardpage() - Awajax.forminitsave() - Awapphost.formlaunch(tcForm: 'form1_scx', tlSubForm: .F., m.tcSuffix: '') - A form previously instantiated bares the same name: "form1_scx"
Also, I am still not able to use the studio to launch the webserver engine. I have to go through the FAA and publish each time.
Thanks, steve