Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
FP98 and browser side script
Message
General information
Forum:
Internet
Category:
FrontPage
Title:
FP98 and browser side script
Miscellaneous
Thread ID:
00239970
Message ID:
00239970
Views:
45
I have now wasted over 40 hours of my spare time trying to conquer simple browser side scripting in a FP98 web. The only thing I have accomplished is disappointment and understanding what you can't do with script in FP98. In order to atleast accomplish something fruitful from this, I thought I would throw out the following heads up warnings in hope that I save somebody else the hassles I've been through.

General notes:
Need custom scripted functionality? Dont use FP98.

Don't bother looking for any M$ Knowledge Base articles for anything other than basic product info because this is not a developers tool so there is no useful technical information other than what ISP's need to know to install FP extensions.

Insert menu - Advanced - Script:
This dialog is only useful if you want to code server-side VBScript. Any clientside JavaScript entered here gets place in the body section (instead of header section) of your html document.

Any clientside JavaScript entered here gets prefaced with a paragraph tag in your html doc which basically flags it as "ignore me"

Any clientside JavaScript entered here will not show up the next time you bring up this dialog, yet it's still in the body of your html file.

Don't bother trying to define your global variables here, then use them in the Script Wizard like the M$ press books recommend. You'll end up with the variable defined twice... neither of which are in the right place! This of course leads to page load errors and GPFs in FP Editor when you go to the preview tab. (you gotta love a code generation tool that generates faulty code and crashes on it #@!$%&*)

Script Wizard and javascript:
If you define a global variable, then try to use it, you wont get what you expect. The var definition statement will show up in your html doc after and event script where you try to use that variable.
Don't use global variables... put the var statement at the begining of a Procedure where you want to use it. This makes it a local variable in some respects, but thats the only way you can get the variable defined before you use it.

You can not disable form controls/fields and have them appear to be diabled. And if you try and do something with a disabled control that doesn't appear to be disabled... boy oh boy IE4 doesn't like it one bit!!! Netscape on the other hand just ingores the FP code disabling the control and errors out on the next line of script no matter what.

You can not reference an individual radio button, nor a group of radio buttons, in anyway shape or form. About the only thing you can do with a radio button is to let FP validation (which generates the script for you) make sure one of the group was selected. If you try and duplicate the exact same validation code (that FP generates for this) in your own procedure, it wont work. AND the code witll die a miserable death once loaded into a browser!!!

Beware of if (some expression) statements. If the coding is flat out wrong you will get an error when the page loads. If the expression can not be evaluated (and it usually can't if it uses a global variable or references a radio button) it will NOT be assumed to be a false result, but rather it is assumed to be a true expression and the statements immediately following it will be run no matter what.

if statements only work in procedures you define yourself, and not in event code.

for statements only work in procedures you define yourself, and not in event code.

Dont bother trying to add anything to the Form's OnSubmit event if your using any FP generated validation... your code will disappear and be replaced with the default return statement as soon as you close the script wizard dialog.

Don't try and insert any window actions from the insert actions pane of the Script Wizard anywhere, they are bogus and generate an error on page load.

Beware of setting focus from an event that normally sets focus to the next control (like OnChange() ). Your scripted actions are run before the default event behavior, so often you set it to control 3 in your script and then the default behavior carries the focus forward to control 4.

Netscape doesn't like you setting focus in script anyway (in an FP98 page atleast).

Beware of using the VS6 Miscrosft Development Environment for debugging script from a FP98 web. It will let you debug and fix things, but upon returning to FP your going to crash and burn & corrupt your FP registry settings in most cases.

No sense in editing your script anywhere but in the Script Wizard, FP just reverts it back to an incorrect form once you open the page in editor.

Beware of forgetting to terminate a statement with a semicolon, the whole statement often disappears once you save the page.

(end of warning)

Now somebody go ahead and ask me if I'm ever going to willing use FP again after I take this MCSD elective exam!!!!! Go ahead & ask... I dare ya! =D)
Roxanne M. Seibert
Independent Consultant, VFP MCP

Code Monkey Like Fritos
Next
Reply
Map
View

Click here to load this message in the networking platform