Odd script behaviour

Moderators: Phil Winkler, Graham Smith, Pete Tabord

Odd script behaviour

Postby Gil Fleming » Tue Feb 21, 2017 4:59 pm

We have a customer screen which gives access (via subform) to the various assemblies (products) that that particular customer buys from us. As customers can buy as many as 50 or 60 different products from us, we introduced a simple A-Z choice field method for reducing the number of sub-records displayed (see 1st pic)

ffPic1.png
ffPic1.png (105.2 KiB) Viewed 2981 times


However, some customers tended to call all of their products by the same base name (eg ffcleaner1, ffcleaner2, ffcleaner3 etc). We therefore added a 'find' option where you could enter additional search text to locate the required sub record (see 2nd pic).

ffPic2.png
ffPic2.png (106.56 KiB) Viewed 2981 times


The script that fired on this choice field was as follows:
Code: Select all
if AssSelectionEntry.value = "FIND" then
AssSearchText.visible := 1 .
AssSearchText.ReDraw := 1 .
AssSearchField.visible := 1 .
AssSearchField.ReDraw := 1 .
else
AssSearchField.value := "" .
AssSearchText.visible := 0 .
AssSearchText.ReDraw := 1 .
AssSearchField.visible := 0 .
AssSearchField.ReDraw := 1 .
End

This popped up the search box when needed and blanked it/hid it if you changed your mind. The odd behaviour was if we selected products beginning with 'F'. This had the effect of showing the search box, as if we had selected find.

The following script mod sorted the problem, but I don't know why the problem happened in the first place:
Code: Select all
if AssSelectionEntry.value = "F" then
AssSearchField.value := "" .
AssSearchText.visible := 0 .
AssSearchText.ReDraw := 1 .
AssSearchField.visible := 0 .
AssSearchField.ReDraw := 1 .
else
if AssSelectionEntry.value = "FIND" then
AssSearchText.visible := 1 .
AssSearchText.ReDraw := 1 .
AssSearchField.visible := 1 .
AssSearchField.ReDraw := 1 .
else
AssSearchField.value := "" .
AssSearchText.visible := 0 .
AssSearchText.ReDraw := 1 .
AssSearchField.visible := 0 .
AssSearchField.ReDraw := 1 .
end
end


Any ideas?
Gil Fleming
Director
Fleming Technical Limited

You can't think about what you don't know - Mike Fidler
If you can't fight, wear a big hat - John S Fleming
The best way to have a good idea is to have lots of ideas - Linus Pauling
Gil Fleming
 
Posts: 546
Joined: Tue May 15, 2012 10:26 am
Location: Liverpool, UK
Has thanked: 1 time
Been thanked: 2 times
 

Re: Odd script behaviour

Postby Adrian Jones » Wed Feb 22, 2017 7:49 am

Just "F"? Not "FI" or "FIN"?

What happens if you add a check on the length of value:

field.value = "FIND" and length ( field.value ) = 4
User avatar
Adrian Jones
 
Posts: 2000
Joined: Tue Sep 11, 2007 2:38 pm
Location: Cornwall, UK
Has thanked: 5 times
Been thanked: 4 times
 

Re: Odd script behaviour

Postby Gil Fleming » Wed Feb 22, 2017 10:14 am

Adrian, it's a choice field displayed as a big radio button, the idea being that your selection filters the displayed sub records. The default choice is ALL, which displays all sub records. Then, selecting an alphabet letter should display all sub records beginning with that letter. The first script was added to open a search box if you selected the FIND option. It all worked perfectly until we noticed that selecting the letter F also triggered the script put there to catch the FIND option. The second script fixes the bug but I don't understand why the script put there to detect the FIND option was fired by selecting F. I was hoping that team ffenics could help but they seem to be more like team ffeniczzzzzzzz. :roll:
Gil Fleming
Director
Fleming Technical Limited

You can't think about what you don't know - Mike Fidler
If you can't fight, wear a big hat - John S Fleming
The best way to have a good idea is to have lots of ideas - Linus Pauling
Gil Fleming
 
Posts: 546
Joined: Tue May 15, 2012 10:26 am
Location: Liverpool, UK
Has thanked: 1 time
Been thanked: 2 times
 

Re: Odd script behaviour

Postby John Middleton » Thu Feb 23, 2017 10:58 am

Gill

We always used to use a virtual field derived directly from choice fields as these were always unreliable in DFW days. I think they store minimalistic data – not true data.

As I recall the ‘value’ parameter retrieves data from the underlying table, whereas the ‘string’ is what the user has typed or chosen.

When we were short of screen real estate for our EPoS software (for newspaper rounds & re-ordering processes) we used subforms nested within subforms to display the wider position, with a simple click to drill down – achievable from anywhere on the form

I’m unsure as to why your customers create their own description of your products? Why do they reassess the form – to reorder? Wouldn’t some small images of the products assist them?

John
ShopEase
John Middleton
 
Posts: 110
Joined: Mon Sep 10, 2007 3:14 pm
Location: England
Has thanked: 0 time
Been thanked: 1 time
 

Re: Odd script behaviour

Postby Gil Fleming » Thu Feb 23, 2017 11:53 am

John, this is our internal system for customer assemblies, some of which are own-label ie the product name is chosen by the customer. I was just intrigued as to why the ffenics script that looked for the 'FIND" option was also triggered by the "F" option. I know that choice fields are stored as their choice numbers, and then referenced to the list of choices (or they were in DFD), but it still doesn't make sense, especially as the modified script that looks specifically for the "F" isn't triggered by the "FIND" option. I'm feeling dizzy now. #-o
Gil Fleming
Director
Fleming Technical Limited

You can't think about what you don't know - Mike Fidler
If you can't fight, wear a big hat - John S Fleming
The best way to have a good idea is to have lots of ideas - Linus Pauling
Gil Fleming
 
Posts: 546
Joined: Tue May 15, 2012 10:26 am
Location: Liverpool, UK
Has thanked: 1 time
Been thanked: 2 times
 

Re: Odd script behaviour

Postby John Middleton » Thu Feb 23, 2017 1:56 pm

Gill

Misbehaving ‘Choice’ field problems have cropped up many times over the years – right from DFD days – with the Compuserve Forum. Fred Kingston described them as “the work of the devil”. And yes the choices were stored as numbers.

There were suggestions that the use of an impromptu jointext in queries helped????

So, some 25 years plus – it would seem it still ain’t fixed.

Which event fires the choice – PostEdit?

John
ShopEase
John Middleton
 
Posts: 110
Joined: Mon Sep 10, 2007 3:14 pm
Location: England
Has thanked: 0 time
Been thanked: 1 time
 

Re: Odd script behaviour

Postby Gil Fleming » Thu Feb 23, 2017 5:27 pm

John

The choice field contains the letters of the alphabet, plus "ALL" and "FIND" , giving rise to 3 possible scenarios:

1. If the user clicks a letter of the alphabet, a separate field is populated by concatting the letter with *, so if you click N, the field is populated with N*. This separate field is the related field to the product assemblies in the subform, so that only assemblies with a description matching N* (ie all the Ns) are shown. The derivation checks that the length of the selection is 1, meaning that a single letter selection has been made.

2. If the user clicks "ALL", the related field is simply populated with a *, thereby showing all sub records. Again, the derivation checks the length of the clicked value as 3 (ALL = 3 chars) and populates accordingly

3. If the user clicks "Find", a script fires on the ValueLoaded event which makes visible a search field, allowing you to enter additional text, which is then concatted with * before and after the entry (so that "noz" becomes "*noz*" ) and put into the related field, thereby allowing a more flexible filtering of the sub records. If you subsequently click a different option in the choice field, the search box is blanked and hidden.

Simple, but it works well. A bit like me, really :mrgreen:
Gil Fleming
Director
Fleming Technical Limited

You can't think about what you don't know - Mike Fidler
If you can't fight, wear a big hat - John S Fleming
The best way to have a good idea is to have lots of ideas - Linus Pauling
Gil Fleming
 
Posts: 546
Joined: Tue May 15, 2012 10:26 am
Location: Liverpool, UK
Has thanked: 1 time
Been thanked: 2 times
 

Re: Odd script behaviour

Postby John Middleton » Fri Feb 24, 2017 11:28 am

Gill

I understand how your Choice field functions, but you were wondering why your script had to be modified so that it could differentiate between “F” and “Find”.
As I noted previously the PostEdit ‘String’ parameter hold the user’s input data, whilst the ‘Value’ parameter is retrieved from the properties of the (at table level) edit field.

The ValueLoaded event fires twice for each record. You appear to have no error catch for this eventuality. DE (usually) never held a Boolean value for the event return () with both (0) and (1) being True and any other value being False. I assume FF is the same? A dummy outer loop in the script will ignore the erroneous first firing and provide an error trap – which is more or less mandatory for good programming.

John
ShopEase
John Middleton
 
Posts: 110
Joined: Mon Sep 10, 2007 3:14 pm
Location: England
Has thanked: 0 time
Been thanked: 1 time
 
 

Return to Ffenics 1.x

Who is online

Users browsing this forum: No registered users and 9 guests

cron