Notifcation receiving Notify's in reverse order?

1

So back to this 5 year old problem again Clarion events being processed in a LIFO and not FIFO order - ClarionHub

So using notify in a callback procedure to process the Systray Icon mouse clicks.

Mouse Down is obviously triggered first which sends a Notify, then Mouse Up is triggered which sends yet another notify, yet the window using Notification to receive and process the Notify messages is receiving them in the reverse order.

How can I get Notification to work on a FIFO basis?

The help suggests it is working in a FIFO manner, but not on my machine it isnt!

TIA

2

Some explanation, I introduced NOTIFY/NOTIFICATION in C6 as a replacement for one of variants of SETTARGET which has become unusable after switching to the preemptive multi-threading. This is why EVENT:Notify events are placed to the head of event queue. Possibility to pass some data between threads safely is just a side effect and if a program uses this side effect it must live with it.

Probably, it’s better to use the POST function instead of NOTIFY. If some data must be passed, the THREADed queue can be using for that.

1 Like
3

So does the Clarion POST use the win32 api PostMessageA function (winuser.h) - Win32 apps | Microsoft Learn or SendMessage function (winuser.h) - Win32 apps | Microsoft Learn then?

Taken from SendMessage, PostMessage, and Related Functions - Win32 apps | Microsoft Learn

4

POST places a Clarion event to the event queue of the top WINDOW of the current (if the 3rd parameter is omitted) thread or of the thread identified by the 3rd parameter if it is passed.
PostMessage, SendMessage, etc. are functions working with Windows messages and message queues of User objects of specific type (windows). Nothing in common.
How POST places events to an event queue in another thread depends from event and from Clarion version. In some cases the RTL uses the SendNotifyMessage API function for that.

1 Like
5

The help does NOT say it works FIFO or LIFO, it just says Notify puts the Event “at the FRONT of the Event Queue” i.e. First.

In his post Brahn concludes that with multiple NOTIFY()'s sent the effect is LIFO (not FIFO), that the Last Notify IN will be the First one OUT when the Event Queue is read. I agree.

Event Queue: Before

  1. Event:Selecting
  2. Event:Selected

Event Queue: After your 1st Notify( Down_Mouse )

  1. Event:Notify - Down_Mouse - put 1st
  2. Event:Selecting
  3. Event:Selected

Event Queue: After your 2nd Notify( Up_Mouse )

  1. Event:Notify - Up_Mouse - put 1st
  2. Event:Notify - Down_Mouse - was 1st now 2nd
  3. Event:Selecting
  4. Event:Selected

Next time ACCEPT pops Event 1 off the Queue it will get "Notify Up_Mouse " which is the Last Notify() … that pushed it First on the Queue before Down_Mouse … so Notify works “Last In First Out” = LIFO. Posting at the Front makes Notify like a Stack.

It cannot. Maybe in your Notify(, Parameter) you could use some kind of Unique ID to match the Down and Up pair. Or easier just don’t use Notify use Post. Must your events really move to the front of the line, there cannot be many pending events that will interfere.

6

I think, if you want to guarantee a FIFO thing, maybe create a class to manage it with a Queue instead of trusting the order of received events.

1 Like
7

Thats a good idea, at least it removes or reduces the ability of outside influence ie viruses/malware interfering with OS functions.

8

But it would be helpful if it did though rather than having undocumented behaviour.

After all, its a matter of perspective with this new independent threading model, because once the first notify has been sent and notification received, I’d expect the receiving thread to action the notification, but there is a delay so it doesnt get actioned immediately, consequently the second notify is sent out and notification received and then it it becomes a LIFO.

If there wasnt a delay actioning the received notification, it could be considered FIFO. This is the problem, so @jslarve suggestion’s to use a queue in the class, is a way of creating a buffer to process the notifications in order.

9
  • The RTL places all non-modal events generated internally to the tail of corresponding event queue.
  • If the last parameter of POST is TRUE (1), this event is being placed to the head of queue. Otherwise, POSTed event is being placed to the tail of queue.
  • NOTIFY places the EVENT:Notify event to the head of event queue

The RTL “shows” events in WINDOW’s ACCEPT loop from head to tail.

Modal events assume some response from the code in the ACCEPT loop (CYCLE, BREAK or normal reaching the END paired to ACCEPT). Therefore the ACCEPT loop is invoking immediately for such events without placing them to the queue.

In my opinion, all this is documented.

10

Ideally you code your application so that the order that events are received does not matter.

1 Like
11

I don’t think this contradicts my statement.

12

What you have put is documented in the help, dont dispute that, but the problem I’m experiencing is the delay in the events being processed can cause problems, namely a FIFO becomes LIFO, when dealing with mouse events. There is no mention of this in the documents.

With a keyboard there can only ever be two events, keypress down and keypress up, but with a mouse there can be just a single mouse down event and single separate a mouse up event and no paired mouse down and mouse up events, because the user can press and hold down a mouse button on the systray icon and then move the mouse point off and away from the systray icon.

Likewise a user can press and hold down a mouse button on an empty part of the desktop or taskbar and whilst still holding down the button can move the mouse pointer over the systray icon before releasing the mouse button, generating a mouse up event.

Like I said previously, you cant do those actions with a keyboard because the keys cant be moved and so dont generate a position.

So using post and sending the event to the back of the queue seems to be the only way to process these mouse events in the correct order.

I disagree with that, because the order of events is in itself important meta data, that can be used to highlight outside interference.

So I’ve written an app in the past, which posted events to another app to interfere with it for testing purposes, it could as you would put it, generate events in any order but this is why its important events are received and processed in order.

Those Win32 API’s I posted above are now subject UIPI constraints.
[User Interface Privilege Isolation - Wikipedia]
(User Interface Privilege Isolation - Wikipedia)
because posting events and other messages can be used to create one of these attacks.
Shatter attack - Wikipedia

However there is still a way to mess around with other programs so events are not processed in the right order and that can still cause problems.