I am using global event listener in my application. The event capture perfectly works in my code. The problem is the event seems to be fire multiple time. I have followed this tutorial link.
If your app is listening to global events generated by system, then these events may fire several times according to conditions you do not know. On my experience to get a univocal signal from the system I had to analyze a sequence of global events and the signal was recognized as received only when this sequence of events occured one after another in expected way.
If your app is listening to global events generated by your application, then it is fully under your control. Check your code that fires global events. Use EventLogger to log every moment when you fire and when you receive fired event. Then inspect your log to find out what is going on. Seems that your app fires the global event more times than expected.
Related
tldr Why don't I receive PBT_APMRESUMEAUTOMATIC, PBT_APMRESUMESUSPEND, and PBT_APMSUSPEND as the payload to service events of type SERVICE_ACCEPT_POWEREVENT?
I'm trying to detect when a windows device as woken back up from sleep. I have a constellation of processes that interact via IPC, which includes both UI applications with an event handler function provided to RegisterClassEx and services using RegisterServiceCtrlHandlerExW.
My preference is to receive these events in a service. My understanding is that I can get SERVICE_ACCEPT_POWEREVENT in dwControlsAccepted, and can then distinguish specific kinds of power event by looking at the dwEventType parameter, as per these docs https://learn.microsoft.com/en-us/windows/win32/api/winsvc/nc-winsvc-lphandler_function_ex. However, I only ever receive PBT_APMPOWERSTATUSCHANGE, corresponding to fiddling with the power cord on the laptop. I expected to also receive some combination of PBT_APMRESUMEAUTOMATIC, PBT_APMRESUMESUSPEND, and PBT_APMSUSPEND.
When testing on the UI side, I do get WM_POWERBROADCAST events of any kind. Obviously I've missed some part of setup there. Again, the process that actually needs this info is a service, so I would have to IPC the event to a service if this is what ended up working.
For full credit, I also experimented with SERVICE_CONTROL_CONTINUE and SERVICE_CONTROL_PAUSE (enabled via SERVICE_ACCEPT_PAUSE_CONTINUE), but never receive these events at all. I had expected those to correlate with sleeping the laptop but apparently not.
I've been studying a lot of the common ways that developers design/architect an application on domain driven design (Still trying to understand the concept as a whole). Some of the examples that I saw included the use of events via an event aggregator. I liked the concept because it truly keeps the different elements/domains of an application decoupled.
A concern that I have is: how do you rollback an operation in the case of an error?
For example:
Say I have an order application that has to save an order to the database and also save a copy of the order as a pdf to a CMS. The application fires an event that a new order has been created and the pdf service that subscribes to this event saves the pdf. Meanwhile when committing the order changes to the database an exception is thrown. The problem is that the pdf has been saved but their isn't a matching database record.
Should I cache the previously handled events and fire a new error event that looks to the cache for "undo" operations? Use something like the command pattern for this?
Or... is the event aggregator not a good pattern for this.
Edit
I'm starting to think that maybe events should be used for less "mission critical" items, such as emailing and logging.
My initial thought was to limit dependencies by using the event aggregator pattern.
You want the event to be committed in the same transaction as the operation on your database.
In this particular scenario, you can push the event on a queue, which enlists in your transaction, so that the event will never go out unless the aggregate is persisted. This will make creating the PDF eventual consistent; if creating the PDF fails, you can fix the problem, and have it automatically retried.
Maybe you can get more inspiration in one of my previous posts on eventual consistent domain events with RavenDB and IronMQ.
Handling an event before it actually happened (committed) only works if the event handler participates in the transaction. Make the event handler transactional (for instance by storing the PDF in a database), or publish and handle events after the transaction committed.
How do I store events as part of setting up my tests?
Currently I'm initializing application state by sending commands like this:
Given some commands were sent
When sending another command
Then some events should have been published
I'm using ICommandService.Execute() to send the Commands in the Given and When parts.
Since commands can be rejected by the domain, I wouldn't want to rely on them. I'd rather set up my application state by simulating events like this:
Given _some events_ occurred
When sending a command
Then some events should have been published
How do I push the events from Given into the event store so that they can be replayed during handling the "When" part?
Thanks
Dennis
Have been given the answer on the mailing list and will add this for further reference:
I was using an old version of Ncqrs. The current version exposes Ncqrs.Eventing.Storage.IEventStore.Store() which takes an event stream and can be uses during test set-up just as needed.
I am in support of an application that involves serial port communication.
There are 32 MSComm controls (control array) on the form.
Suppose data arrived at one of the com port while some other code of the same thread is running (say database access etc.). will the Oncomm event procedure queed for execution or the current execution point is queed and Oncomm event handler is executed?
VB6 is single threaded. Basically (excepting ActiveX controls for a second) there's just the GUI thread.
It's sitting there waiting for an event. You get data, so it enters the event handler for your MSComm control and starts doing some database access. It blocks waiting for the database to respond. Another MSComm control receives data and fires off an event. This event just sits in the Windows event queue. The GUI thread has to exit the event handler before it can process the other MSComm event.
Of course, in the middle of an event handler you can call DoEvents. I highly suggest you rarely, if ever, do that. It's the source of many difficult bugs, in my experience.
There are ways to queue the long running database work onto a background thread (using a call into .NET managed code, in that case). That will allow your event handler code to continue almost immediately without blocking, allowing it to process the next message. To my knowledge, there's no native VB6 way to do that.
I am porting a library to Windows. In a function I need to block on the arrival of a WM_DEVICECHANGE message.
What options are available for doing this? As my code resides in a library I have little-to-no information on the current set-up (so if it is a Console application, a regular GUI application, if my code is being run in a spawned thread, and so on). Therefore what is the best way to wait for the arrival of a specific message?
Blocking and receiving Windows messages are mutually incompatible. You get messages by pumping a message loop. Since you cannot rely on the app pumping one, you'll need to do this yourself.
You will need to create a thread. Create a hidden window in that thread then run the standard message loop. The window procedure for that window can see the WM_DEVICECHANGE message. It can do what ever it needs to do, within the constraints of running inside a separate thread. Like setting an event to signal that a function should stop blocking.
The message is probably sent using BroadcastSystemMessage(). You could create a hidden top-level window and its window proc would probably get this message. I'm not sure; but that's what I'd try first.