PG Software Development

Hi Clifton,

I've been having trouble using the value returned for mouseEvents. I have a number of buttons that the user is required to hold down to start a timer which moves objects amongst other things. When the button is allowed to come up this timer is stopped. It generally functions well but sometimes there is a problem. I originally used the condition if value contains "mousedown" to distinguish between mousedown and mouseup but sometimes this doesn't work so I use if item 2 of value = "mousedown" instead. The strange thing is some buttons "like" one condition and others don't! If one condition works the other one doesn't. Have you ever seen anything like this before. It's not a great problem because I can achieve what I want to do.

John

I'll look into this, but it would be better if you could package up an example where this is happening.
 

Unfortunately I can't reproduce the problem in a simple app. Here are some pictures:

Here is the value returned:



What is happening seems incomprehensible to me. On certain buttons if the condition is item 2 of value = "mousedown" works then value contains "mousedown" doesn't work and vice-versa!





But don't worry about it. To show you I would need to send you all the files and there are quite a lot. If I ever finish this part of the program and the problem is still there, I'll send you everything but don't hold your breath!

I will try and replicate this and see what I can figure out.
At first mention, this may come down to an issue with ToolBook v9, which you have been using. Version 9 was the first version to use the item x of [stack] expression. It could be that this does not always translate very well (though I'm not aware of any problem) and it could be that the button name ending in a digit may be causing some confusion.

Nevertheless, I will look at this to see what I can come with.

For what it is worth, you could try getItemFromStack() and see if that produces consistent results or it anomalies are seen there too. Not that you would use it instead of your logic, but at least we could start troubleshooting the item x of [stack] scenario to see what is happening.
 

My tests are consistently returning the correct item 2 of [value] result. You might try naming the button to something more unique. For example, a button named "b4" will not process at all because "b#" generally is reserved for background id's in ToolBook.

Since your application is pretty complicated, you check if you are firing a periodic timer on the page which could interferes with consistent results from the user event sent when a mousedown or up occurs.

Not really sure though.
 

Hi Clifton,
Thanks for all your efforts. I hope this has not been a wild goose chase. The buttons are now all behaving themselves and will accept either condition as you would expect then to. I've no idea what happened or what changed to make them function as planned. One thing I did notice was that a local variable called value had been created. I am certain that I did not create this variable and strangely it was created for both the user Event and the click event. Also it seems that it was only created for the buttons that were misbehaving!?

PS As it happens, I do use fields called b1 - b5 (that look like buttons) in a completely different part of the program but I have not noticed any anomalies.

I would recommend extending the names of objects like "b1", "b2", etc. to something like "b_1", "b_2", to protect yourself from frustration that could occur with a collision between background id's and object names. For example, if your fields were buttons, they would not be located by the PowerPac referencing engine. I tried this and a button named "b1" returns the background of the page rather than the button object "b1". As soon as I change the button name to something else, like "B1" or "myb1", all is fine.

NOTE: "B1", "B2", etc. names work because JavaScript is case-sensitive and ToolBook background ids fall into the range of lowercase "b1", etc.
 

Thanks. I'll check this.
Any thoughts about the mysterious appearance of the local variable value? Although the buttons now work with or without it I wonder if it wasn't causing the problem because its value would have been "".

Not sure on the variable issue. It is pretty hard to create a variable called [value] from JavaScript (PowerPac) because ToolBook uses other names for referencing variables behind the scenes. The only place where such a variable could be created where the actions would reference it is right from within the Actions Editor itself. And of course, have a variable called [value] is likely to cause conflicts, at least when a user event occurs which relies of a parameter called [value]. A variable called value is likely to trump a parameter by the same name.

If this anomaly appears again, try and see if you can track it down to a specific object and event.

Is there any restriction on the use of p + number to name an object. I have a new problem now. Buttons p5 to p8 should have userProperty set to mouseEvents but they're not responding to user Event. i.e. they won't alert value.

UPDATE:
Yes, there is! I guess it's creating a confusion with page 1 etc. I have renamed the buttons pause1, pause2 etc. and this solves the problem.