I have not looked at the product code yet, but off the top of my head, this is a bad coding practice. MOUSE triggers are not intended for use on buttons. This is why we have a WHEN-BUTTON-PRESSED trigger. If you don't want the behavior of a button then don't use a button. Instead use a Display or Image item or other object, but not a button. This is not a bug.
Consider this, forget about the Mouse trigger for a moment, the event that is fired when you click the button will fire one time for each cycle of pressing down then releasing. So if you double-click a button the BUTTON-PRESSED trigger will fire twice. It has no awareness of a "double-click" concept, so it fires each time a down then up action occurs. This is expected behavior. So if you try to add MOUSE triggers to this, all of these events will be sent to the server and appear as though things are being duplicated when actually they are not.
Again, MOUSE triggers are not intended to be used with buttons. Do so at your own risk.
i added the mouse triggers only for investigation.
if you have a button menu and double click on a button in 6i the Trigger would be fired once.
In 184.108.40.206 the Trigger is fired twice. This brings up problems.
What would you suggest? The user might always from his windows understanding do a double click on the button.
Let me check into it and get back with you. I suspect, as I mentioned that the Forms Java client has no awareness of a double-click on the context of a button, so the event is sent twice. Likely it would fire three times if you rapidly clicked three times. This would not surprise me as it is only responding to what you are doing, clicking...
I will update this post as soon as I know more.
Development has confirmed that each time you press/click on a button the expected behavior is the corresponding trigger will fire. So if you click a button three times you should expect to see the trigger fire three times. However, as you noted, if you try to interrupt that flow with a modal window/alert or similar, the subsequent trigger execution (WHEN-BUTTON-PRESSED) may not fire. This cannot be avoided nor can such a condition be detected before it happens.
1. You double click a button, but don't do it fast enough.
2. The first event from the client makes it to the server and the server sends a message back that forces an Alert to be displayed. Regardless of whether you see the Alert or not, the client received the request and is processing it. At this point the client will not accept any more input until after this alert is rendered. But while in this state the user does the second click of a double click. Because the client is now in a wait state, that second click is never heard. It's almost as if the user clicked outside the form. So the trigger only fires one time.
This is just one example of how the behavior you are seeing might happen. There are likely others.
Although unrelated, I wanted to mention that Dev also confirmed that using MOUSE triggers on buttons (push button, radio button, and even check boxes) should be avoided. In most cases, we will not accept bug filing against undesired behavior resulting from such a configuration. If the default button behavior is not desirable, consider extending it with a PJC or create your own button with a Java Bean.
Have you considered a form level WHEN-MOUSE-DOUBLE-CLICK trigger?
As it is form level, it would fire for everything, display items, text items, buttons etc.
If you detect what sort of object you are in when the WMDC trigger fires you could do nothing/ignore the double click action unless you were in e.g. a text item.
IF :SYSTEM.TRIGGER_ITEM IS NOT NULL THEN
IF get_item_property(:SYSTEM.TRIGGER_ITEM, ITEM_TYPE) = 'TEXT ITEM' THEN
-- maybe do something based upon the item type (get_item_property(:SYSTEM.CURSOR_ITEM, DATATYPE);
-- if it's a date and call a calendar, a number call a calculator...
Thank you "beans" for your Suggestion.
my main problem is that with 6i the When-Button-Pressed trigger fires one time with Mouse doubleclick and fires two times with 220.127.116.11.
So I have to prevent with a coding like in my example the second call of the logic behind When-Button-Pressed.
Maybe my explanation was not precise enough.