This has got to be a bug?

[user#606]

I attach a test stack developed on a macbook (mentioned in case there is no problem with it on a PC)
Objective:
if there is content in table field then the line in second field is bold.
if table field is empty then the line in second field is normal text.
NB if text is entered in the table field and then deleted, tabs are left behind that render the table with invisible content, so the routine to replace TAB with "" has been used.

The actual bug is illustrated by the change in the Answer result.
you will (I hope) see that if you enter text into the table field, press button, delete text in table field, press button, the answers that follow subsequent display of result in Answer should always be the same. They are not, the first pass is different to those that follow.

What do you make of it?

PS. I have since found out that it works properly on the PC after setting Format for printing and the removal of TABs is not required either.
Will try the Macbook again tomorrow, it might put itself right!

[bn]

Hi user#606,
I think it has to do with the fact that the table field uses a temporary field to make the entries. As long as the field has the focus this temporary field is still present. If you do enter text in the field and press the button the field still has focus. Once you invoke the answer dialog the field loses focus and the number is correct. In my testing it is always the first answer dialog that has the wrong length of the field.
To get this consistent you just have to insert a "select empty" after replacing the tab.
I post your script with the addition of the "select empty"

Code: Select all

on mouseUp
   local Tcard1091,temp
   put empty into Tcard1091 
   replace tab with "" in field "AddressLogBkTxt1"
   select empty
   put the length of field "AddressLogBkTxt1" into temp
   answer temp
   put the length of field "AddressLogBkTxt1" into temp
   answer temp
   put the length of field "AddressLogBkTxt1" into temp
   answer temp
   put the length of field "AddressLogBkTxt1" into temp
   answer temp
   if field "AddressLogBkTxt1" > 0 then put 1 into Tcard1091
   --answer Tcard1091
   If Tcard1091 > 0 then --This is to bolden content line if > 0
      set the textStyle of line 1 of field "BldgLogContent" on card id 1002 to "bold"
   else
      set the textStyle of line 1 of field "BldgLogContent" on card id 1002 to "normal"
   end if
     
end mouseUp

this gives you consistently the numbers you would expect.
In case there are returns in the field they would still count.

If you really want to know whether there is any text in the table field or not then you have to take account of the tabs and the returns

here is a version of your script that has a function to do that. Look at "function noOfCharsWithoutReturnAndTab"

Code: Select all

on mouseUp
   local Tcard1091,temp
   put empty into Tcard1091 
   replace tab with "" in field "AddressLogBkTxt1"
   select empty
   put the length of field "AddressLogBkTxt1" into temp
   answer temp
   put the length of field "AddressLogBkTxt1" into temp
   answer temp
   if noOfCharsWithoutReturnAndTab (field "AddressLogBkTxt1") > 0 then put 1 into Tcard1091
   If Tcard1091 > 0 then --This is to bolden content line if > 0
      set the textStyle of line 1 of field "BldgLogContent" on card id 1002 to "bold"
   else
      set the textStyle of line 1 of field "BldgLogContent" on card id 1002 to "normal"
   end if
     
end mouseUp

function noOfCharsWithoutReturnAndTab pText
   replace tab with "" in pText
   replace cr with "" in pText
   return length (pText)
end noOfCharsWithoutReturnAndTab

Kind regards
Bernd

[user#606]

Thank you for the useful function, I will add it to my library, as I am sure others will too.

However, the stack works differently on MAC than PC and this means the cross platform claim is false.

First, the extras you suggest to make the MAC work as required, are not needed on the PC.

Second, there is still another problem on both platforms that has come to light and it is most odd. If a value is typed into the table field and ENTER is pressed, the script in the button runs and this is undesirable under any circumstances. There is no script in the table field, so why is ENTER calling it. Many users prefer the ENTER key to TAB when progressing through fields. There is no good reason for the button to be activated or even highlighted at that time.

I am not looking for a workaround, just confirmation that this is not acceptable behaviour for either the first (cross platform) inconsistency or the second, running of uncalled for scripts.
If you agree, I can pass this on to REV as a bug.

[bn]

Hi user#606,

However, the stack works differently on MAC than PC and this means the cross platform claim is false

If I am not mistaken the platforms behave differently when you click a button. As far as I know (not quite shure) on Windows the field looses focus if you click a button, not on a Mac. That is why you have to take the focus from the table field in the script.

I think that the button reacts to the Enter key has to do with the fact that you made it a default button, the blue pulsating one on the mac. If you turn that off in the properties inspector for the button, (uncheck default) then it behaves well.

So I dont think these are really bugs, they are either due to the interface guidelines of the platform or in case of the default button how you have set it up.

Kind regards

Bernd

[user#606]

Hi Bernd
I have not seen any hint of these differences in the user guide or dictionary, perhaps I missed them.
Not easy for new users to follow these subtle differences, is it.
Where are these issues explained, how did you find them, and what others are there for cross platform developers to be aware of.

Thank you for the advice, anyway, it allows me to progress.
Alan

[bn]

Hi Alan,

these things are part of the respective operating system.

Acutally there are not many things to watch out for. You found one thing.
Most people have problems with fonts crossplatform. The fonts even if they are the same, e.g. Helvetica, run a little different on the different operating system. Some people use Verdana on Windows and Lucida Grande on Mac. So you would have to test for that on the system itself. It is how fonts are rendered by the operating system. Menues are a problem. There are hints on how to do them for Windows and Mac.
I don't do cross platform development, so all I know is from what I picked up here and there.
In case of doubt just ask here in the forum.

regards

Bernd