Set Multiple
- James Bott
- Posts: 4654
- Joined: Fri Nov 18, 2005 4:52 pm
- Location: San Diego, California, USA
- Contact:
Enrico,
It looks like your new code might solve the MDI-Child issue. Although this line:
IF UPPER( cTitle ) $ UPPER( GETWINDOWTEXT( hWnd ) )
Might be safer done this way:
IF UPPER( cTitle ) == left( UPPER( GETWINDOWTEXT( hWnd ), len(cTitle) )
In the code I posted, I discovered that GETWINDOWMODULEFILENAME() is returning some strange results. I created some code to just list the module names with the window handles and here is a section of the results. The number is the window handle, followed by the module filename.
-------------------
11/23/07 13:26:09: Init: 21300590 <<-- this is the correct handle
11/23/07 13:26:18: 65954
11/23/07 13:26:18: 65954
11/23/07 13:26:18: 65956
11/23/07 13:26:18: 394182
11/23/07 13:26:18: 3080390 C:\FW\Test\Test26.exe
11/23/07 13:26:18: 459312 C:\FW\Test\Test26.exe
11/23/07 13:26:18: 65694 C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2982_x-ww_ac3f9c03\comctl32.dll
11/23/07 13:26:18: 196676
11/23/07 13:26:18: 1180570
11/23/07 13:26:18: 7079288 C:\FW\Test\Test26.exe
11/23/07 13:26:18: 65680
11/23/07 13:26:18: 131210
11/23/07 13:26:18: 196682
11/23/07 13:26:18: 196678
...
------------------------
Strangely, lots of the window handles don't have module names and some of the module names are listed multiple times (my test program is test26.exe) and there are others including some by Microsoft. Test26 was listed probably about 50 times. Since GETWINDOWMODULEFILENAME() is just an API call, I am at a loss as to why it isn't working properly.
James
It looks like your new code might solve the MDI-Child issue. Although this line:
IF UPPER( cTitle ) $ UPPER( GETWINDOWTEXT( hWnd ) )
Might be safer done this way:
IF UPPER( cTitle ) == left( UPPER( GETWINDOWTEXT( hWnd ), len(cTitle) )
In the code I posted, I discovered that GETWINDOWMODULEFILENAME() is returning some strange results. I created some code to just list the module names with the window handles and here is a section of the results. The number is the window handle, followed by the module filename.
-------------------
11/23/07 13:26:09: Init: 21300590 <<-- this is the correct handle
11/23/07 13:26:18: 65954
11/23/07 13:26:18: 65954
11/23/07 13:26:18: 65956
11/23/07 13:26:18: 394182
11/23/07 13:26:18: 3080390 C:\FW\Test\Test26.exe
11/23/07 13:26:18: 459312 C:\FW\Test\Test26.exe
11/23/07 13:26:18: 65694 C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2982_x-ww_ac3f9c03\comctl32.dll
11/23/07 13:26:18: 196676
11/23/07 13:26:18: 1180570
11/23/07 13:26:18: 7079288 C:\FW\Test\Test26.exe
11/23/07 13:26:18: 65680
11/23/07 13:26:18: 131210
11/23/07 13:26:18: 196682
11/23/07 13:26:18: 196678
...
------------------------
Strangely, lots of the window handles don't have module names and some of the module names are listed multiple times (my test program is test26.exe) and there are others including some by Microsoft. Test26 was listed probably about 50 times. Since GETWINDOWMODULEFILENAME() is just an API call, I am at a loss as to why it isn't working properly.
James
- Enrico Maria Giordano
- Posts: 7355
- Joined: Thu Oct 06, 2005 8:17 pm
- Location: Roma - Italia
- Contact:
This wouldn't work if cTitle were contained inside the window caption.James Bott wrote:IF UPPER( cTitle ) == left( UPPER( GETWINDOWTEXT( hWnd ), len(cTitle) )
Yes, I know. That's why I searched a different solution.James Bott wrote:In the code I posted, I discovered that GETWINDOWMODULEFILENAME() is returning some strange results.
EMG
- James Bott
- Posts: 4654
- Joined: Fri Nov 18, 2005 4:52 pm
- Location: San Diego, California, USA
- Contact:
Enrico,
>This wouldn't work if cTitle were contained inside the window caption.
True. MDI apps, by default, append the title of the child window to the app title, so it would work fine under these circumstances. Of course the programmer could change the title and this would break it.
Alternately, any given title could also occur within another apps title so searching for the title anywere in the window title of all windows could likewise fail to work properly. That is why using the module file name would be a better solution (provided the needed function was working).
Jamess
>This wouldn't work if cTitle were contained inside the window caption.
True. MDI apps, by default, append the title of the child window to the app title, so it would work fine under these circumstances. Of course the programmer could change the title and this would break it.
Alternately, any given title could also occur within another apps title so searching for the title anywere in the window title of all windows could likewise fail to work properly. That is why using the module file name would be a better solution (provided the needed function was working).
Jamess
- nageswaragunupudi
- Posts: 8017
- Joined: Sun Nov 19, 2006 5:22 am
- Location: India
- Contact:
Relying on Mutex is the best way and thats what IsExeRunning() function does. I have been using Mutex for this purpose earlier.
But I have a doubt which I would be glad if the author of the function Mr Enrico clarifies.
I used to Create the mutex at the beginning of the program and ReleaeMutex at the end of the program ( even otherwise Windows is supposed to do the cleanup of releasing the handle and destroy the mutex object). Because the Mutex was owned by the Initial Owner ( first invocation of the program ) through out its execution, second and subsequent invocations of the same program fail.
But in the IsExeRunning() function the Mutex is created and also Released immediately. And the program continues its execution. I am not able to understand why the second initiation is unable to create the mutex again, when it was already released by the first instance? I agree this function is working but I am unable to understand how? Can you kindly clarify Mr Enrico ?
But I have a doubt which I would be glad if the author of the function Mr Enrico clarifies.
I used to Create the mutex at the beginning of the program and ReleaeMutex at the end of the program ( even otherwise Windows is supposed to do the cleanup of releasing the handle and destroy the mutex object). Because the Mutex was owned by the Initial Owner ( first invocation of the program ) through out its execution, second and subsequent invocations of the same program fail.
But in the IsExeRunning() function the Mutex is created and also Released immediately. And the program continues its execution. I am not able to understand why the second initiation is unable to create the mutex again, when it was already released by the first instance? I agree this function is working but I am unable to understand how? Can you kindly clarify Mr Enrico ?
Regards
G. N. Rao.
Hyderabad, India
G. N. Rao.
Hyderabad, India
- Enrico Maria Giordano
- Posts: 7355
- Joined: Thu Oct 06, 2005 8:17 pm
- Location: Roma - Italia
- Contact:
The answer is simple: ReleaseMutex() only "releases ownership of the specified mutex object" and doesn't destroy the mutex object itself.nageswaragunupudi wrote:But in the IsExeRunning() function the Mutex is created and also Released immediately. And the program continues its execution. I am not able to understand why the second initiation is unable to create the mutex again, when it was already released by the first instance?
EMG
Last edited by Enrico Maria Giordano on Sun Nov 25, 2007 10:35 am, edited 1 time in total.
- nageswaragunupudi
- Posts: 8017
- Joined: Sun Nov 19, 2006 5:22 am
- Location: India
- Contact:
Mr Enrico
Thanks.
Is it possible to destroy the mutex in the application and continue application? I did not find DestroyMutex function in msdn.
My requirement is this. When one instance is performing cetrain function, the other instances should wait to do some dependent functions.
Thanks.
Is it possible to destroy the mutex in the application and continue application? I did not find DestroyMutex function in msdn.
My requirement is this. When one instance is performing cetrain function, the other instances should wait to do some dependent functions.
Regards
G. N. Rao.
Hyderabad, India
G. N. Rao.
Hyderabad, India
- James Bott
- Posts: 4654
- Joined: Fri Nov 18, 2005 4:52 pm
- Location: San Diego, California, USA
- Contact:
Nageswara,
>My requirement is this. When one instance is performing cetrain function, the other instances should wait to do some dependent functions.
Why not just use a function containing a static var. When one process is complete it changes the static to .t. and the other process keeps checking the value.
James
>My requirement is this. When one instance is performing cetrain function, the other instances should wait to do some dependent functions.
Why not just use a function containing a static var. When one process is complete it changes the static to .t. and the other process keeps checking the value.
James
- nageswaragunupudi
- Posts: 8017
- Joined: Sun Nov 19, 2006 5:22 am
- Location: India
- Contact:
This is in the context of several instances running on a server. While one instance is performing a particular task, other instances need to wait to do some dependent tasks. I use Globa/ namespace for mutexes.
I am considering using semaphores or some other ipc mechanism. But still interested to know how to destroy a mutex without closing the application.
Right now I am adopting crude but dependable method of locking some records on ads table. Works but I think its not elegant.
I am considering using semaphores or some other ipc mechanism. But still interested to know how to destroy a mutex without closing the application.
Right now I am adopting crude but dependable method of locking some records on ads table. Works but I think its not elegant.
Regards
G. N. Rao.
Hyderabad, India
G. N. Rao.
Hyderabad, India
- Enrico Maria Giordano
- Posts: 7355
- Joined: Thu Oct 06, 2005 8:17 pm
- Location: Roma - Italia
- Contact:
- nageswaragunupudi
- Posts: 8017
- Joined: Sun Nov 19, 2006 5:22 am
- Location: India
- Contact: