This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
10711
Web Server - Ask For Help / Re: validate delete from a browse
« on: August 01, 2008, 05:37:12 AM »
Hi Kevin,
The PreDelete routine in the form is the place it _should_ go.
However it has been a long while since I played with the Delete code, so I won't swear to it.
Ray's issue is different - in his case he has a multi-component key.
Cheers
Bruce
The PreDelete routine in the form is the place it _should_ go.
However it has been a long while since I played with the Delete code, so I won't swear to it.
Ray's issue is different - in his case he has a multi-component key.
Cheers
Bruce
10712
Web Server - Ask For Help / Re: Are html validator errors going to cause problems?
« on: August 01, 2008, 05:34:47 AM »
Hi Mike,
The short answer is no, it's not a problem for browsers.
The slightly longer answer is that, from time to time, I feed the examples to the Validator and tidy up whatever I can. I don't think it's ever been _completely_ complaint (there are some button naming issues I need to sort out) but there are no "really bad" things as far as I know.
Cheers
Bruce
The short answer is no, it's not a problem for browsers.
The slightly longer answer is that, from time to time, I feed the examples to the Validator and tidy up whatever I can. I don't think it's ever been _completely_ complaint (there are some button naming issues I need to sort out) but there are no "really bad" things as far as I know.
Cheers
Bruce
10713
Web Server - Ask For Help / Re: track incoming IP address
« on: August 01, 2008, 05:31:13 AM »
Hi Kevin,
Mikes explanation is great. I can add very little except to say;
you can get the IP of the current request using
p_web.GetSessionIP()
Thus anywhere you are currently logging stuff, you can add the IP number of the client to your log.
Cheers
Bruce
Mikes explanation is great. I can add very little except to say;
you can get the IP of the current request using
p_web.GetSessionIP()
Thus anywhere you are currently logging stuff, you can add the IP number of the client to your log.
Cheers
Bruce
10714
Web Server - Ask For Help / Re: Forcing the Cancel button or just cancelling the save
« on: July 29, 2008, 08:03:50 AM »
Hi Ray,
Let's start by covering a couple of bases, then move on from there.
a) Validation can happen at several points during the Form. There's what I call "immediate validation" where fields are checked, as they are entered, and there's also "before save" validation which happens after the save button is pressed. Although the two are both doing valuation, the approach to "how to fail" is quite different. (hold onto this thought for a moment and we'll come back to it...)
b) The URL on the SAVE button is set when the form is _generated_. Also put the "everything was ok" URL in here. Typically when validation fails, it remains on the current form. So the Save URL is the "where to go when validation passes" link.
c) The recent pre-releases of 4.31 contain some extended (better) support for Immediate Validation, and an example, so if you're wanting to do immediate validation then perhaps work with this.
http://www.capesoft.com/ftp/public/prerelease/index.htm
For purposes of your question I'm gonna assume that we'll add some validation after the user presses Save. If the validation fails it will return to the form, if it succeeds it'll proceed to the URL you've set for the Save button. For now I won't discuss Immediate Validation.
The Validation you are going to add will take place in the ValidateRecord routine. You could use ValidateInsert and ValidateUpdate, but ValidateRecord covers both the Insert and Update cases.
here you add what ever code you like to _test_ whether the form is valid. It's also one of the very few places where you can access File Variables directly (eg cust:invoicenumber) - but for non-file-variables you should use p_web.GetValue('whatever')
If the record is ok, you set nothing, and the server proceeds to the URL specified by the Save button.
If the record is not ok, then you set 3 things;
loc:invalid = 'Loc:Login'
p_web.SetValue('retry','LoginForm.Htm')
loc:Alert = 'Login Failed. Try Again.'
The first is loc:invalid. Set this to the "name" of the invalid field. (This will provide a visual indicator to the user, and also set the cursor to the right place.) Notice the quotes, the name is in a string.
The second is the "retry" parameter. This (by default) contains the name of the form procedure, however in your case you want to set it to match the "current web page htm file name". This is the direct answer to one of your questions, by setting the retry parameter you can specify the URL it goes to now that it has failed.
The 3rd item is loc:alert. Whatever string you put in here will appear in red (which you can override) on the form as it appears. It will also (by default) appear as a popup on the client computer. This is all overrideable, but we'll worry about that later.
Cheers
Bruce
Let's start by covering a couple of bases, then move on from there.
a) Validation can happen at several points during the Form. There's what I call "immediate validation" where fields are checked, as they are entered, and there's also "before save" validation which happens after the save button is pressed. Although the two are both doing valuation, the approach to "how to fail" is quite different. (hold onto this thought for a moment and we'll come back to it...)
b) The URL on the SAVE button is set when the form is _generated_. Also put the "everything was ok" URL in here. Typically when validation fails, it remains on the current form. So the Save URL is the "where to go when validation passes" link.
c) The recent pre-releases of 4.31 contain some extended (better) support for Immediate Validation, and an example, so if you're wanting to do immediate validation then perhaps work with this.
http://www.capesoft.com/ftp/public/prerelease/index.htm
For purposes of your question I'm gonna assume that we'll add some validation after the user presses Save. If the validation fails it will return to the form, if it succeeds it'll proceed to the URL you've set for the Save button. For now I won't discuss Immediate Validation.
The Validation you are going to add will take place in the ValidateRecord routine. You could use ValidateInsert and ValidateUpdate, but ValidateRecord covers both the Insert and Update cases.
here you add what ever code you like to _test_ whether the form is valid. It's also one of the very few places where you can access File Variables directly (eg cust:invoicenumber) - but for non-file-variables you should use p_web.GetValue('whatever')
If the record is ok, you set nothing, and the server proceeds to the URL specified by the Save button.
If the record is not ok, then you set 3 things;
loc:invalid = 'Loc:Login'
p_web.SetValue('retry','LoginForm.Htm')
loc:Alert = 'Login Failed. Try Again.'
The first is loc:invalid. Set this to the "name" of the invalid field. (This will provide a visual indicator to the user, and also set the cursor to the right place.) Notice the quotes, the name is in a string.
The second is the "retry" parameter. This (by default) contains the name of the form procedure, however in your case you want to set it to match the "current web page htm file name". This is the direct answer to one of your questions, by setting the retry parameter you can specify the URL it goes to now that it has failed.
The 3rd item is loc:alert. Whatever string you put in here will appear in red (which you can override) on the form as it appears. It will also (by default) appear as a popup on the client computer. This is all overrideable, but we'll worry about that later.
Cheers
Bruce
10715
News And Views / Re: NetTalk Pre-Release 9 version 4.31 available
« on: July 28, 2008, 06:37:33 AM »
We're closing in on a candidate release with this one.
Cheers
Bruce
Cheers
Bruce
10716
Web Server - Ask For Help / Re: Problem displaying data on an htm page
« on: July 24, 2008, 10:40:34 PM »
The original problem has been fixed in 4.31 (Pr8)
10717
Web Server - Ask For Help / Re: When does CallClicked routine get called?
« on: July 24, 2008, 10:38:55 PM »
Hi Mike,
when on a form, the click _is_ bing trapped - but it's going to the Form embed rather than the browse. I am working on a mechanism though to pass it through the form, and on to the browse in that situation.
For now though, you can "see" the click in the form procedure.
Cheers
Bruce
when on a form, the click _is_ bing trapped - but it's going to the Form embed rather than the browse. I am working on a mechanism though to pass it through the form, and on to the browse in that situation.
For now though, you can "see" the click in the form procedure.
Cheers
Bruce
10718
Web Server - Ask For Help / Re: Server side click code not getting touched...
« on: July 24, 2008, 04:27:29 AM »
see
http://www.capesoft.com/docs/NetTalk/NetTalkWebFAQ.htm
Question W4
(regarding URLs calling a Form)
Cheers
Bruce
http://www.capesoft.com/docs/NetTalk/NetTalkWebFAQ.htm
Question W4
(regarding URLs calling a Form)
Cheers
Bruce
10719
Web Server - Ask For Help / Re: When does CallClicked routine get called?
« on: July 24, 2008, 04:22:20 AM »
Hi Mike,
If the browse is on a form, then the click is (currently) likely to be swallowed by the form (ie in the Validate::<whatever> routine in the form) rather than be passed onto the browse.
Cheers
Bruce
If the browse is on a form, then the click is (currently) likely to be swallowed by the form (ie in the Validate::<whatever> routine in the form) rather than be passed onto the browse.
Cheers
Bruce
10720
Web Server - Ask For Help / Re: File Upload Tracking
« on: July 24, 2008, 02:53:55 AM »
ha - yeah, you got it in 1, the whole Post arrives before it even thinks about starting to process it...
So it's not as simple as just looking at a file.
Cheers
Bruce
So it's not as simple as just looking at a file.
Cheers
Bruce
10721
Web Server - Ask For Help / Re: range limit browse with double key
« on: July 24, 2008, 02:50:09 AM »
Hi Ray,
I've sent you an example, but the biggest issue you've got is mixing the concepts of "key", "sort order" and "range".
a) You don't select the key for the View to use - the View engine does that. So just forget the key for now.
b) when setting the default sort order, make sure you use the right field (in this case the Title) and most importantly make sure you set the CASE SENSITIVE switch correctly. By correctly, I mean that if you _have_ a key, that you think the View Engine can use, then you must make sure your sort order matches that key. If the key is Case Insensitive, then the field must be as well, and vice versa.
Cheers
Bruce
I've sent you an example, but the biggest issue you've got is mixing the concepts of "key", "sort order" and "range".
a) You don't select the key for the View to use - the View engine does that. So just forget the key for now.
b) when setting the default sort order, make sure you use the right field (in this case the Title) and most importantly make sure you set the CASE SENSITIVE switch correctly. By correctly, I mean that if you _have_ a key, that you think the View Engine can use, then you must make sure your sort order matches that key. If the key is Case Insensitive, then the field must be as well, and vice versa.
Cheers
Bruce
10722
Web Server - Ask For Help / Re: Date lookup issue: Only @D6, @D2 supported
« on: July 24, 2008, 12:19:46 AM »
Hi Vince,
My point is that @D17 will always be the Server setting.
You might be able to get the setting from the client using JavaScript (but honestly I doubt it.)
Cheers
Bruce
My point is that @D17 will always be the Server setting.
You might be able to get the setting from the client using JavaScript (but honestly I doubt it.)
Cheers
Bruce
10723
Web Server - Ask For Help / Re: File Upload Tracking
« on: July 24, 2008, 12:12:53 AM »
Hi Devan,
It's been a while since I experimented with this.
As I recall, once you do the POST you're not gonna get anything to update on the window until the post is completed.
Thus in order to have the progress bar, you need to do the Post as the ajax call, and then use a timer to update the progress. There are scripts out there that do this sort of thing, but I've not integrated any in yet.
Cheers
Bruce
It's been a while since I experimented with this.
As I recall, once you do the POST you're not gonna get anything to update on the window until the post is completed.
Thus in order to have the progress bar, you need to do the Post as the ajax call, and then use a timer to update the progress. There are scripts out there that do this sort of thing, but I've not integrated any in yet.
Cheers
Bruce
10724
Web Server - Share Knowledge / FireFox 3 and NetTalk 4.30 and before
« on: July 24, 2008, 12:07:13 AM »10725
Web Server - Ask For Help / Re: Date lookup issue: Only @D6, @D2 supported
« on: July 18, 2008, 11:30:41 PM »
Hi Vince,
Do they want to support the @d17 as it is on the _server_ or the D17 of the _client_ machine?
The JavaScript calendar currently built-in is limited to @d6 or @d2. However typically one of these is right. If you want the date format to match the _client_ then you need to take a slightly different approach.
Of course this limitation is limited to entry fields only - you can use any date picture when displaying a date.
Cheers
Bruce
Do they want to support the @d17 as it is on the _server_ or the D17 of the _client_ machine?
The JavaScript calendar currently built-in is limited to @d6 or @d2. However typically one of these is right. If you want the date format to match the _client_ then you need to take a slightly different approach.
Of course this limitation is limited to entry fields only - you can use any date picture when displaying a date.
Cheers
Bruce