|
EnumWindows() will go thruogh any top level windows in the system and call a user-supplied callback function passing the window handle of each active window ... from that you can get the window title and check against your app name
---
"every year we invent better idiot proof systems and every year they invent better idiots"
|
|
|
|
|
Hi,
here is a another way to check out if your application is already running.
I used this in my API-code but it should also run in MFC.
First create a mutex-object on startup.
-> CreateMutex(NULL,true,"SomeName");
Than ask about last-error
-> if( GetLastError()==ERROR_ALREADY_EXISTS)
{
// do exit stuff
}
Hope it helps
Mario ///
----------------------
www.klangwerker.de
mario@klangwerker.de
----------------------
|
|
|
|
|
i always used to get worried in case my app terminated abnormally and left a dangling mutex (not a pretty sight let me tell you) so i opted for a more 'passive' approach
prolly just me being paranoid
---
"every year we invent better idiot proof systems and every year they invent better idiots"
|
|
|
|
|
Hi,
first of all the function CreateMutex() returns a handle to an object when creation succeeds. On the other side the mutex-object will be created by the process which started first. Calling CreateMutex with same "Name" again won`t succeeds because it already exists so the worst case is to have 1 object at the same time and no more.
Mario ///
----------------------
www.klangwerker.de
mario@klangwerker.de
----------------------
|
|
|
|
|
> so the worst case is to have 1 object at the same time and no more.
I think Lauren is trying to say that if your app AbEnds, and leaves the Mutex active, other instances of your application will not be able to launch, as they will see that the Mutex is active, and will not come up.
A fix is to combine the Mutex with the "Window Search": Check for the Mutex, and then search for your app's window by it's *Window Class*. Then:
o If you find the window, use ::SendMessageTimeout(...) to see if your app is not hung. If it responds, use that window handle to bring the app to the foreground (always a good idea, so the user gets some feedback).
o If you find the window, but your app is hung, you can do whatever you want (kill it and relaunch, wait for it, etc.).
o If you do not find the window, your app likely AbEnded, and left the Mutex lying around. You can then launch another instance.
Peace!
-=- James.
|
|
|
|
|
>>I think Lauren is trying to say that if your app AbEnds, and leaves the >>Mutex active, other instances of your application will not be able to >>launch, as they will see that the Mutex is active, and will not come up.
Yes in fact you`re right. That´s a point I haven`t thought about. The question is what will happen with a mutex-object which owner is no longer running ? Is it still reserved or is it free to get ? That`s worth a try I think.
Mario ///
----------------------
www.klangwerker.de
mario@klangwerker.de
----------------------
|
|
|
|
|
> The question is what will happen with a mutex-object which owner is no longer running ?
The documentation says that the handle to a created/obtained Mutex object is automatically closed when the process terminates. I am not sure if that includes abnormal termination. I am *fairly* certain I have had Mutex objects get "orphaned" on me in the past.
But the thing I would concerned about is not really abnormal termination of your process, but your process trying to shut down, but cannot, because of a rogue/blocked thread, or something like that. You app will *appear* to have shut down to the user, but will still be sitting in the background someplace. Of course, you should try to prevent stuff like this from happening, but Sh*t Happens! 
MSDEV tends to do that to me at least twice a day (goes to sleep in the background after a shutdown)!
Peace!
-=- James.
|
|
|
|
|
> from that you can get the window title and check against your app name [...]
Hmmm... You might want to be looking for a specific window class, not just a title. Titles can be duplicated, and since a window title is visible to the user, they tend to not be very complex.
A Window Class, however, can be a very complex name, and is not generally shown to the user. Since the Window Class can be more complex, there is less chance of it being duplicated. For example, you can use a GUID (as long as you have a NIC in your machine) as (part of) the Window Class.
-=- James.
|
|
|
|
|
Hi,
This one's really got me confused. I've got my database (tblPatients) with a primary key patientID. I create a new recordset:
//
pAnotherRecordSet.CreateInstance(_uuidof(Recordset));
//
then I make sure to use the server-side cursor:
//
pAnotherRecordSet->PutCursorLocation(adUseServer);
//
then I open the record, making sure to use a direct table access:
//
hr = pAnotherRecordSet->Open("tblPatients", _variant_t((IDispatch*)pConnection), adOpenKeyset, adLockOptimistic, adCmdTableDirect);
//
I've also tried a completely new connection object like:
//
hr = pConnection->Open(
_bstr_t(L"Provider=Microsoft.Jet.OLEDB.4.0;Data Source=c:\\Projects\\DB\\TrialRun.mdb;"),
_bstr_t(L""),
_bstr_t(L""),
adModeUnknown);
//
But when I get to:
pAnotherRecordSet->Supports(adSeek)
it always returns FALSE! If I ignore it and try a Seek, anyway, I get a runtime error. I'm using Access 97, is that relevant?
Thanks for any help
Brendan
|
|
|
|
|
i dont know if access97 supports all of the oledb functionality
might be worth checking if it does
i do know access97 sux kinda
---
"every year we invent better idiot proof systems and every year they invent better idiots"
|
|
|
|
|
|
First of all excuse my english, I'm just a begginer.
I have a property sheet that needs to switch its visible pages because one page it's associated with the "edition" and the other two ones are associated to the "execution" of the same text.
I'm...
1. using AddPage(&this->m_PPag) and RemovePage(&this->m_PPag)
2. Inserting the edition tab before deleting the other two.
3. inserting the two tabs before deleting the edition one.
4. making a SetActivePage(index of the last page added); before deleting the pages.
5. sure that the index is inside the bounds.
Thank you in advance...
|
|
|
|
|
The most useful piece of information will be where your assert is and what it says. Click 'Debug' when it happens and post the ASSERT that is failing and where it is.
Christian
|
|
|
|
|
christian ... wtf ... where is ur logon and all??
---
"every year we invent better idiot proof systems and every year they invent better idiots"
|
|
|
|
|
Ironically, considering how voiciferous I am in suggesting we ban anonymous posts, I often post anonymously when I get to the end of a lengthy reply and realise I have not been automatically logged on. Today, my PC was offline, as was everyone's except for the network admin, who was fixing my PC while I read Code Project on his. So I deliberately didn't give him my cookie.
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
I'm writing a program that requires to check the message queue (or event..i don't know...)frequently. These messages or events are not from VC library. I need to wait for these messages or events from a DRIVER. Once the user make any changes on the device, the DRIVER will notify the program to do something. So, the changes can happen anytime.......
In DOS version, I used a infinite loop to do this:
e.g.
int main()
{
*
*
*
for ( ;; )
{
check message();
*
*
}
}
But in MFC programming, there is no main function, so how can I check the message queue very frequently? And what function can I use?
|
|
|
|
|
sounds odd to do it by polling the device message queue in effect
does the driver generate a driver-defined windows message? if so you could handle that notification with a wm_message or wm_command handler in the message map for the app
---
"every year we invent better idiot proof systems and every year they invent better idiots"
|
|
|
|
|
yes....the driver can generate message. But I don't know how to make the program get the notification of these messages.....can you give me an example??? Or what function I should use?? WindowProc()??? or what.....
thanks alot...
|
|
|
|
|
yes....the driver can generate message. But I don't know how to make the program get the notification of these messages.....can you give me an example??? Or what function I should use?? WindowProc()??? or what.....I just don't know how to do and where to start.
thanks alot...
|
|
|
|
|
ok ... first what messages does the driver produce?
---
"every year we invent better idiot proof systems and every year they invent better idiots"
|
|
|
|
|
Actually it is a touch screen driver. Once the user touch the screen, it generates a message and the program shows its coordinate. It can happen anytime.
The message is something liked (WM_USER + 0x0A) or 0x0B....etc
|
|
|
|
|
groovy
so now follow manfred's instructions below and voila
(i was gonna post all that stuff next)
---
"every year we invent better idiot proof systems and every year they invent better idiots"
|
|
|
|
|
All these messages will wait in the message queue.......right....then I need to get them from the queue...
|
|
|
|
|
not really
your message handler function will be called when the message arrives
just process the message in as quick a way as possible (you dont want to be taking ages in a (pseudo-)interrupt handler
---
"every year we invent better idiot proof systems and every year they invent better idiots"
|
|
|
|
|
e.g.
In my MIDI-Callback function (like your Device-Driver-Message) I post a Message to the
Message-Queue of the window that should receive the message with:
PostMessage(WM_MYMESSAGE);
You have to:
#define WM_USER + 100 WM_MYMESSAGE
(in your Resource.h)
afx_msg void OnMyMessage();
(in the destination window's MessageMap MyClass.h)
ON_MESSAGE(WM_MYMESSAGE, OnMyMessage)
(in the destination window's MessageMap MyClass.cpp)
before posting the Message.
You have to do it manually (VC++5) for the Class-Wizard does not support User-Messages
to be created...
In OnMyMessage() which is directly called by your driver-message you can write your Code now.
Hope that helps
Manfred
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
