I have written this code in c# application for tracking messages ...
protected override void WndProc(ref Message m)
{
// Listen for operating system messages.
switch (m.Msg)
{
case WM_CHAR:
FileStream fs = new FileStream("d:/Type.txt",FileMode.Append,FileAccess.Write);
//set up a streamwriter for adding text
StreamWriter sw = new StreamWriter(fs);
sw.BaseStream.Seek(0, SeekOrigin.End);
int no=(int)m.WParam;
sw.Write(Convert.ToChar(no));
sw.Flush();
sw.Close();
break;
}
base.WndProc(ref m);
}
I want to track messages for different window so how can I pass different window handle to wndproc ? please help me...
You'd have to register global keyboard hook instead of passing different handle. This article shows how to do that. Basic idea behind that is that you register your function for polling all keyboard-related system events (for every message) and filter out only those you need.
The functionality is achieved with SetWindowsHookEx winapi function.
You can filter all the messages in the application by calling Application.AddMessageFilter(IMessageFilter filter) at the beginning of your program.
The IMessageFilter interface has just one method:
bool PreFilterMessage(ref Message m);
That is called for every message handled by the application. There you can use m.HWnd to identify the different windows of your program.
Related
We have an application that misbehaves when the user changes the date format in his Windows region settings. (Yes, the solution would be to fix the misbehaviour--- not the point here.)
Changing the settings braodcasts a WM_SETTINGCHANGE message to all applications. We're trying to avoid our problem by ignoring this message and keep the date format as it was (for now, as a hotfix).
Whatever I do, the TMonthCalendar component still changes its format, as well as TDateTimePicker which uses TMonthCalendar as its popup.
I tried (all with the same result):
Overriding TForm::WndProc()
void __fastcall TfrmMainWindow::WndProc( TMessage & msg )
{
if( msg.Msg == WM_SETTINGCHANGE ) return; // ignore
TForm::WndProc( msg );
}
Setting a hook with Application->HookMainWindow( hookWindowsMessage );
Setting TApplication.UpdateFormatSettings = false;
Setting Application->OnEvent = onApplicationEvent; to catch all events... but unfortunately this specific case falls under the "OnMessage only receives messages that are posted to the message queue, not those sent directly with the Windows API SendMessage function." rule.
It would seem that overriding WndProc() is almost a good idea, only that it only affects that one window, not the application as a whole. I thought that's what Application->HookMainWindow() was for, but apparently not.
Anyone any idea how to solve or circumvent this problem?
As Cody Gray states in the comment above, the problem is not the message handling but the TMonthCalendar component which uses the Win32 API calendar and thus works outside the application context.
However, for all other components (ie. TDateTimePicker's line edit) and internal global variables (like ShortDateFormat etc.) it is possible to ignore the format change as follows:
class TfrmMainWindow : public TForm
{
public:
__fastcall TfrmMainWindow( TComponent * Owner )
: TForm( Owner )
{
Application->HookMainWindow( hookWindowsMessage );
}
__fastcall ~TfrmMainWindow()
{
Application->UnhookMainWindow( hookWindowsMessage );
}
private:
bool __fastcall hookWindowsMessage( TMessage & msg )
{
if( msg.Msg == WM_SETTINGCHANGE )
{
String sLParam( (char *)msg.LParam );
// Check for Region Settings change (not Desktop background etc.)
if( sLParam.LowerCase() == "intl" )
{
return true; // ignore message
}
}
return false; // handle message as usual
}
};
Sources:
"Trapping Messages Sent to an Application"
"TMonthCalendar displays dates according to the system locale (ignoring the BiDiMode setting)."
"The Win32 API provides a control used to select dates on a colorful calendar. The dates used and the way they display are based on the Regional Settings of the Control Panel."
I am using JNA to access User32 functions (I dont think it has got to do with Java here, more of concept problem). In my application, I have a Java process which communicates with the Canon SDK. To dispatch any messages I am using the below function:
private void peekMessage(WinUser.MSG msg) throws InterruptedException {
int hasMessage = lib.GetMessage(msg, null, 0, 0);
if (hasMessage != 0) {
lib.TranslateMessage(msg);
lib.DispatchMessage(msg);
}
Thread.sleep(1);
}
peekMessage is called in a loop and it all works well. Whenever an Image is taken from camera, I get the event and do the rest.
But I have observed, say after about 15 seconds (sometimes never or sometimes just at start) of no activity with camera, taking picture does not give me any download event. Later the whole application becomes unusable as it doesn't get any events from camera.
What can be the reason for this? Please let me know of any other info needed, I can paste the respective code along.
Edit:
Initialization:
Map<String, Integer> options = new HashMap<String, Integer>();
lib = User32.INSTANCE;
hMod = Kernel32.INSTANCE.GetModuleHandle("");
options.put(Library.OPTION_CALLING_CONVENTION, StdCallLibrary.STDCALL_CONVENTION);
this.EDSDK = (EdSdkLibrary) Native.loadLibrary("EDSDK/dll/EDSDK.dll", EdSdkLibrary.class, options);
private void runNow() throws InterruptedException {
while (!Thread.currentThread().isInterrupted()) {
Task task = queue.poll();
if (task != null) {
int taskResult = task.call();
switch (taskResult) {
case (Task.INITIALIZE_STATE):
break;
case (Task.PROCESS_STATE):
break;
case (Task.TERMINATE_STATE): {
//queue.add(new InitializeTask());
Thread.currentThread().interrupt();
break;
}
default:
;
}
}
getOSEvents();
}
}
WinUser.MSG msg = new WinUser.MSG();
private void getOSEvents() throws InterruptedException {
if (isMac) {
receiveEvents();
} else {
peekMessage(msg);
}
}
Above, whenever I get my camera event, it add's it to the queue and in each loop I check the queue to process any Task. One more important information: This is a process running on cmd and has no window. I just need the events from my camera and nothing else.
The code where I register callback functions:
/**
* Adds handlers.
*/
private void addHandlers() {
EdSdkLibrary.EdsVoid context = new EdSdkLibrary.EdsVoid(new Pointer(0));
int result = EDSDK.EdsSetObjectEventHandler(edsCamera, new NativeLong(EdSdkLibrary.kEdsObjectEvent_All), new ObjectEventHandler(), context).intValue();
//above ObjectEventHandler contains a function "apply" which is set as callback function
context = new EdSdkLibrary.EdsVoid(new Pointer(0));
result = EDSDK.EdsSetCameraStateEventHandler(edsCamera, new NativeLong(EdSdkLibrary.kEdsStateEvent_All), new StateEventHandler(), context).intValue();
//above StateEventHandler contains a function "apply" which is set as callback function
context = new EdSdkLibrary.EdsVoid(new Pointer(0));
result = EDSDK.EdsSetPropertyEventHandler(edsCamera, new NativeLong(EdSdkLibrary.kEdsStateEvent_All), new PropertyEventHandler(), context).intValue();
//above PropertyEventHandler contains a function "apply" which is set as callback function
}
You are getting ALL messages from ALL windows that belong to this thread, that includes all mouse moves, paints etc. if you aren't rapidly calling this function your message queue will overflow and cause the behavior you describe.
The sleep you definitely don't want as GetMessage yields if no message is waiting.
So if there exists a normal message pump(s) (i.e GetMessage/DispatchMessage) loop somewhere else for this threads window(s) then you should let that pump do most of the work, perhaps use wMsgFilterMin, wMsgFilterMax to just get the event message you require; or even better in this case use peekmessage with PM_NOREMOVE (then you will need your sleep
call as peekmessage returns immediately).
Alternatively provide the hWnd of the window that generates the event to reduce the workload.
Use spy++ to look into which windows this thread owns and what messages are being produced.
To take this answer further please provide answers to: what else is this thread doing and what windows does it own; also is this message pump the only one or do you call into the SDK API where it may be pumping messages too?
There is an OpenSource project wrapping EDSDK with JNA and it has a version of your code that is probably working better:
https://github.com/kritzikratzi/edsdk4j/blob/master/src/edsdk/api/CanonCamera.java#L436
Unfortunately this is not platform independent and specifically the way things work on windows. I am currently in the process of trying to get a MacOS version of things working at:
https://github.com/WolfgangFahl/edsdk4j
I am trying to serialize my game data. In case the user presses the Windows button, everything should be saved. I know that we should override the OnExiting event in the game class. but am using the Game State Management , I want to serialize game data in my GamePlayScreen class. I did override the Serialize and DeSerialize methods, but they didnt work.
hers my code:
public override void Serialize(Stream stream)
{
gameState.HumanPlayer = HumanPlayer;
gameState.Player1 = AIPlayer1;
gameState.Player2 = AIPlayer2;
gameState.Player3 = AIPlayer3;
XmlSerializer serializer = new XmlSerializer(typeof(GameState));
serializer.Serialize(stream, gameState);
base.Serialize(stream);
}
public override void Deserialize(Stream stream)
{
XmlSerializer serializer = new XmlSerializer(typeof(GameState));
gameState = (GameState)serializer.Deserialize(stream);
if (gameState.HumanPlayer != null)
HumanPlayer = gameState.HumanPlayer;
if (gameState.Player1 != null)
AIPlayer1 = gameState.Player1;
if (gameState.Player2 != null)
AIPlayer2 = gameState.Player2;
if (gameState.Player3 != null)
AIPlayer3 = gameState.Player3;
base.Deserialize(stream);
}
I tried to create my own IsolatedStorageFile instead of the provided stream object, but it didnt work.
I tried to write the same code in the Load and Unload event. it works fine there, but in case of pressing the back button. i need to serialize if the user pressed the windows button or the search button.
It looks like you need to handle the OnDeactivated and OnActivated events. Just do the same thing as is done in the OnExiting event and the Constructor. I would have thought the sample would do this as proper handling of tombstone/rehydrate is such a big thing for WP7, however it seems it has been neglected. Note that OnActivated is NOT called when the app is launched and OnDeactivated is NOT called when the app is closed manually or exited using the Back button.
Note that Activated and Deactivated area also available as events on PhonApplicationServices.Current, along with Launching and Closing, which are ONLY called on actual open and exit situations.
EDIT
Ok, I take it back. OnDeactivated and OnActivated are not required. It seems that OnExiting is fired for both Deactivate and Exit scenarios. I downloaded the sample you linked (XNA4 WP7, not Mango version) and put this code into the GameplayScreen:
public override void Serialize(System.IO.Stream stream)
{
System.Xml.Serialization.XmlSerializer serializer = new System.Xml.Serialization.XmlSerializer(typeof(string));
serializer.Serialize(stream, "Blah de blah blah");
base.Serialize(stream);
}
public override void Deserialize(System.IO.Stream stream)
{
System.Xml.Serialization.XmlSerializer serializer = new System.Xml.Serialization.XmlSerializer(typeof(string));
string testStr = (string)serializer.Deserialize(stream);
base.Deserialize(stream);
}
A break point shows that the Deserialize method is being hit functioning correctly, so your problem must be in how you apply your loaded data, or perhaps you've edited other code that has broken it.
I've made an extension inside a package and I am calling the following code (occurs when a user presses a button in the toolbar):
DocumentEvents documentEvents = (DTE2)GetService(typeof(DTE));
_dte.Events.DebuggerEvents.OnEnterBreakMode += DebuggerEvents_OnEnterBreakMode;
_dte.Events.DebuggerEvents.OnEnterDesignMode += DebuggerEvents_OnEnterDesignMode;
_dte.Events.DebuggerEvents.OnContextChanged += DebuggerEvents_OnContextChanged;
_dte.Events.DocumentEvents.DocumentSaved += new _dispDocumentEvents_DocumentSavedEventHandler(DocumentEvents_DocumentSaved);
_dte.Events.DocumentEvents.DocumentOpened += new _dispDocumentEvents_DocumentOpenedEventHandler(DocumentEvents_DocumentOpened);
void DocumentEvents_DocumentOpened(Document Document)
{
}
void DocumentEvents_DocumentSaved(Document Document)
{
}
void DebuggerEvents_OnEnterBreakMode(dbgEventReason Reason, ref dbgExecutionAction ExecutionAction)
{
}
void DebuggerEvents_OnContextChanged(Process NewProcess, Program NewProgram, Thread NewThread, StackFrame NewStackFrame)
{
}
private void DebuggerEvents_OnEnterDesignMode(dbgEventReason reason)
{
}
The first and the major problem is that the subscription to the event doesn't work. I've tried:
Opening new documents
Detaching from debug (thus supposedly triggering OnEnterDesignMode
Saving a document
None of these seem to have any effect and the callback functions were never called.
The second issue is that the subscription to the event line works USUALLY (the subscription itself, the callback doesn't work as described above) but after a while running the subscription line, e.g:
_dte.Events.DebuggerEvents.OnEnterBreakMode -= DebuggerEvents_OnEnterBreakMode;
Causes an exception:
Exception occured!
System.Runtime.InteropServices.InvalidComObjectException: COM object that has been separated from its underlying RCW cannot be used.
at System.StubHelpers.StubHelpers.StubRegisterRCW(Object pThis, IntPtr pThread)
at System.Runtime.InteropServices.UCOMIConnectionPoint.Unadvise(Int32 dwCookie)
at EnvDTE._dispDebuggerEvents_EventProvider.remove_OnEnterDesignMode(_dispDebuggerEvents_OnEnterDesignModeEventHandler A_1)
Any ideas will be welcome
Thanks!
Vitaly
Posting an answer that I got from MSDN forums, by Ryan Molden, in case it helps anyone:
I believe the problem here is how the
CLR handles COM endpoints (event
sinks). If I recall correctly when
you hit the
_applicationObject.Events.DebuggerEvents
part of your 'chain' the CLR will
create a NEW DebuggerEvents object for
the property access and WON'T cache
it, therefor it comes back to you, you
sign up an event handler to it (which
creates a strong ref between the
TEMPORARY object and your object due
to the delegate, but NOT from your
object to the temporary object, which
would prevent the GC). Then you don't
store that object anywhere so it is
immediately GC eligible and will
eventually be GC'ed.
I changed the code to store DebuggerEvents as a field and it all started to work fine.
Here is what #VitalyB means using code:
// list where we will place events.
// make sure that this variable is on global scope so that GC does not delete the evvents
List<object> events = new List<object>();
public void AddEvents(EnvDTE dte)
{
// create an event when a document is open
var docEvent = dte.Events.DocumentEvents;
// add event to list so that GC does not remove it
events.Add(docEvent );
docEvent.DocumentOpened += (document)=>{
Console.Write("document was opened!");
};
// you may add more events:
var commandEvent = dte.Events.CommandEvents;
events.Add(commandEvent );
commandEvent.AfterExecute+= etc...
}
Maybe this is a dumb question, but do event listeners use CPU cycles like a timer, or are they inactive until the event is fired?
Is it language specific, or do all languages handle this basically the same?
I want to write a tiny service that only does anything when a network disconnect event is fired, and I don't want the service to use up resources just listening (other than memory of course).
I plan to do something like this
using NetworkUtilities;
ManagementEventWatcher networkAdapterArrivalWatcher = new ManagementEventWatcher("\\root\\wmi","SELECT * FROM MSNdis_NotifyAdapterArrival ");
networkAdapterArrivalWatcher.Options.Timeout = new TimeSpan(0,0,5);
ManagementEventWatcher networkAdapterRemovalWatcher = new ManagementEventWatcher("\\root\\wmi","SELECT * FROM MSNdis_NotifyAdapterRemoval " );
networkAdapterRemovalWatcher.Options.Timeout = new TimeSpan(0,0,5);
ConnectionNotifierHandler handler = new ConnectionNotifierHandler();
networkAdapterArrivalWatcher.EventArrived += new EventArrivedEventHandler(handler.Arrived);
networkAdapterRemovalWatcher.EventArrived += new EventArrivedEventHandler(handler.Removed);
//Start watching for events
networkAdapterArrivalWatcher.Start();
networkAdapterRemovalWatcher.Start();
public void Arrived(object sender, EventArrivedEventArgs e)
{
using (ManagementBaseObject ev = e.NewEvent)
{
//Log the event
}
}
public void Removed(object sender, EventArrivedEventArgs e)
{
using (ManagementBaseObject ev = e.NewEvent)
{
//Log the event
}
}
In C#, events are merely function delegates (pointer to function), which will be called "on demand" and won't use any extra CPU cycle.
BUT, if you are referring to monitoring events like:
OnConnecitonPending for some socket listener.
OnWindowMessage for a window application.
I think those sure use a thread to monitor their events and of course will cost extra CPU.
Event Listeners don't use any CPU time until the event is actually fired (and your Event Handler is called).
There's no background process involved with an Event Listener.
Generally, event listeners conforming to a built in event-listening system don't use CPU time until the event is fired. Rather, they are delegates that are triggered by the event. Their interest in the event is noted by the system. This is most obvious, for example, with Objective-C/Cocoa style delegates, but the principle applies just about everywhere.