What is pbm_commnotify event in PowerBuilder? How can it be triggered?
global type some_type from Window
...
event commnotify pbm_commnotify
...
end type
on commnotify;
...
end on;
I am working for a project that requires us to convert a system written in Powerbuilder many years ago into a web application. I am new to Powerbuilder and really have no idea how this type of event can be triggered.
Most pbm_xxx event IDs in PowerScript map to wm_Xxx in Win16/Win32.
Your example:
Code for event commnotify is the "event handler" for Win32 message WM_CommNotify.
Be aware:
Some PowerScript event IDs don't map to Win16/Win32 messages.
You may encounter unmapped PowerScript events (events without event IDs).
pbm_custom01, pbm_custom02, ... map to WM_User, (WM_User + 1), ...*
Related
I'm new in Flux/React Native.
I'm quite confused about dispatch vs emit using in Flux.
What is the main difference between them? And what happen when I use same Action Type in dispatch and emit.
For example:
Dispatcher.dispatch({
actionType: 'ACTION1'
});
SomeStore.emit('ACTION1');
In Flux, events are emitted by the store indicating a change in its state. This 'change' event is listened to by views. This will prompt a view to fetch new state from the store. Mind you, the event never contains payload / information about the new state. It is really just what it reads - an event.
Actions are slightly different. While they are indeed events, they are things that occur in our domain eg., Add item to cart. And they carry a payload that contains information about the action, eg.,
{
id: ‘add-item-to-cart’,
payload: {
cartId: 123,
itemId: 1234,
name: ‘Box of chocolates’,
quantity: 1
}
}
Actions are 'dispatched' from the views and the store(s) responds to the dispatch by possibly changing its state and emitting a 'change' event.
So basically:
A view dispatches an action with a payload (usually due to a user interaction) via the dispatcher
The store (which had previously registered itself with the dispatcher)
is notified of the action and uses the payload to change its state and emit an event.
The view (which had previously registered itself with the store) is notified of the change event which causes it to get the new state from the store and change itself.
So that's the difference. And about the question "use same Action Type in dispatch and emit", it doesn't really make sense, does it?
I suggest you read this blog post - http://blog.andrewray.me/flux-for-stupid-people/ (The title means no offence BTW :))
You already know this, but I'll say it again: A unidirectional data flow is central to the Flux pattern. That means data (not control) always flows in one direction.
I'm getting a warning that PostEvent is deprecated and I assume that one is supposed to use PostEventToQueue but it takes two extra parameters and I can't find any documentation on what combination of parameters (one is a queue specification, the other is an event priority) will be equivalent to PostEvent.
PostEventToQueue is for a Carbon Event, not a low-level OS event like PostEvent. If you want to post a keyboard or mouse event, you should use CGEventPost.
Edit to add: To post a mouse down at the current location, I think (untested) that you can do this:
CGEventRef theEvent = CGEventCreate( NULL );
CGEventSetType( theEvent, kCGEventLeftMouseDown );
CGEventPost( theEvent );
CFRelease( theEvent );
I think it'd be reasonable to assume that using the event queue returned by GetMainEventQueue() (or GetCurrentEventQueue if you're on the main thread), and kEventPriorityStandard for the priority, will get you results equivalent to PostEvent.
Be aware, though, that these only affect your own application. Even the old Event Manager probably doesn't have access to an “Operating System event queue” anymore—I wouldn't be surprised if it's just a wrapper around the Carbon Event Manager version. You'd need to switch to CGEvent stuff if you want to post events that can hit other applications.
I am using Canon SDK to get the events from the camera. In the SDK, we register a callback function, which is called when a particular event occurs. I have built a Java wrapper, which communicates with the SDK.
But when the event is triggered, my window doesn't get the event directly. Infact on windows, this is how I get the event and dispatch it to myself:
private static final User32 lib = User32.INSTANCE;
boolean hasMessage = lib.PeekMessage( msg, null, 0, 0, 1 ); // peek and remove
if( hasMessage ){
lib.TranslateMessage( msg );
lib.DispatchMessage( msg ); //message gets dispatched and hence the callback function is called
}
Basically one peeps if the window has received an event or not and then proceeds. On Mac, one can do it using Cocoa by having a NSApplication and WindowServer sends events if any.
I am looking for similar alternative using X11. Any sample code/link will suffice.
PS: This a follow up question to this.
I suppose you are looking for XPeekEvent. The Xlib is very well documented and the manpage for XNextEvent(3) says:
The XPeekEvent function returns the first event from the event queue,
but it does not remove the event from the queue. If the queue is
empty, XPeekEvent flushes the output buffer and blocks until an event
is received. It then copies the event into the client-supplied XEvent
structure without removing it from the event queue.
Example code for displaying a basic Xwindow and a main event loop for handling events can be found (for example) on wikibooks.
I've read the documentation, which says:
ATL supports alternate message maps, declared with the ALT_MSG_MAP macro.
Each alternate message map is identified by a unique number, which you pass to ALT_MSG_MAP.
Using alternate message maps, you can handle the messages of multiple windows in one map.
Note that by default, CWindowImpl does not use alternate message maps.
To add this support, override the WindowProc method in your CWindowImpl-derived class and call ProcessWindowMessage with the message map identifier.
And when I look at WTL, I see message maps like:
BEGIN_MSG_MAP(CCommandBarCtrlImpl)
MESSAGE_HANDLER(WM_CREATE, OnCreate)
MESSAGE_HANDLER(WM_FORWARDMSG, OnForwardMsg)
...
ALT_MSG_MAP(1) // Parent window messages
MESSAGE_HANDLER(WM_INITMENUPOPUP, OnParentInitMenuPopup)
...
ALT_MSG_MAP(2) // MDI client window messages
// Use CMDICommandBarCtrl for MDI support
ALT_MSG_MAP(3) // Message hook messages
MESSAGE_HANDLER(WM_MOUSEMOVE, OnHookMouseMove)
...
END_MSG_MAP()
However, I don't understand:
How they get called. (How does the code know about the existence of the alternate message maps?)
How they differ from default message maps. They all look like they're handling the same kinds of messages for the same windows...
Why they are useful. (Aren't they all for the same window anyway?)
Does anyone have a better explanation for what alternate message maps do?
(A motivation for why they were invented would be very helpful.)
Alternative message map let's you define message handlers within the same map for messages of other windows. Take a look at your map above:
BEGIN_MSG_MAP(CCommandBarCtrlImpl)
MESSAGE_HANDLER(WM_CREATE, OnCreate)
MESSAGE_HANDLER(WM_FORWARDMSG, OnForwardMsg)
...
ALT_MSG_MAP(1) // Parent window messages
MESSAGE_HANDLER(WM_INITMENUPOPUP, OnParentInitMenuPopup)
...
This is class CCommandBarCtrlImpl, it has a window handle associated with it, HWND. All messages go through default map (lines above ALT_MSG_MAP(1)).
Not for some reason, the class wants to handle messages of the parent. It subclasses it using a member class variable, and you come to the point where you need to have your message handlers defined. You cannot add them right into the same map because it would be a confusion with its own window messages.
This is where alternate maps come to help. Parent window messages are routed to alternative message map number 1.
You don't need alternate maps if you only handle messages of your own window.
Starting up a WinEventHook doesn't seem to be working reliably.
What would cause an event hook to only monitor events (or run the identified event proc function) sometimes?
ie. inside an IE8 BHO
HWINEVENTHOOK eHook = ::SetWinEventHook(EVENT_OBJECT_SHOW, EVENT_OBJECT_REORDER
, 0
, MSAALib_WinEventProc
, GetCurrentProcessId(), GetCurrentThreadId()
, WINEVENT_OUTOFCONTEXT );
I've been getting events quite regularly, but after a recent build it doesn't work except when I'm also running MS "Accessible event watcher", stopping and starting the event watcher also stops and starts my event proc being called.
I haven't changed the SetWinEventHook in any recent build so I do not believe this is the cause.
All the other thread/message pumping actions are taking place as expected so I do not believe failure to pump messages on the thread is the cause.
Testing getting reorder events using http://www.quirksmode.org/dom/events/tests/DOMtree.html and adding/removing test elements.
Edit:
Upon further testing it appears the change may have been that I stopped running the "Accessible event watcher" and not the build.
The range of events captured by the event hook without the "Accessible event watcher" appears to be [first, last) or eventMin to eventMax-1 which is not as per the doc SetWinEventHook when starting the "Accessible event watcher" the range changes and appears to be [first,last] so using an eventMax of EVENT_OBJECT_FOCUS seems to get the desired result of seeing EVENT_OBJECT_REORDER.
Is there something I'm missing here, or is the doc just wrong and the event watcher is doing something aswell?