C / C++ / MFC

FindWindow is hanging.... help?

11-Jun-04 9:40

nyquisttt wrote:
how can i show an existing image in a c++ window. I mean i want my code to open a window and display an existing image in that window.

Use a static control and draw the image on it.

"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen

Wes Jones11-Jun-04 6:55

11-Jun-04 6:55

Hi all,

I have an app that uses FindWindow to find the window handle to another app's window, and it looks like it is hanging. It doesn't do it every time, but from my logging statements, I can tell that FindWindow is the last thing called when it's hung up.

I've seen the various articles/comments about the dangers of using FindWindow, ie: uses SendMessage internally & can hang if another app's thread is waiting/hung, etc.

I have written an alternative function for some other purpose that works similarly to FindWindow but checking all the top level windows, starting w/ the desktop window, but that too uses GetWindowText (ie: SendMessage()) & I think will have the same liability.

My question is: What's a good alternative to using FindWindow ?

I would alter my similar function to use SendMessageTimeout, but I am using Windows CE, and that function is not supported.

Please help, won't you?

What are the alternatives to using FindWindow?

here are some details about how I'm using FindWindow

LPCTSTR szPossibleNames[] = 
{  _T("name1"), _T("name2"),...,_T("nameN") };

for(int i=0; i < X; ++i)
{
    if( FindWindow(NULL, szPossibleNames[i]) )
      break;
}
//other stuff...

Is using FindWindow in a loop like this just asking for trouble? It's like I'm making it do risky things over & over again....

Just for fun, and in the case it can help somebody point out an alternative to me, here's the code for my 'alternative func':

HWND FindChildAmongManyChildDialogs(HWND hWndMain, 
                  LPCTSTR szClassName, 
                  LPCTSTR szWindowTitle)
//
//This function was written to 
//find a child window when there is a main 
//window, and then several dialogs that 
//are children, and the window we want 
//is on one of those dialogs.
//
//This is based on the AirCard 555 watcher program,
//and Spy++
//
//
//
{
	CString str, strTitle;
	TCHAR szClass[ 200 + 1 ] = {0};

	CWnd * pChild = CWnd::FromHandle(::GetWindow(hWndMain, GW_CHILD) );
	CWnd * pLast = NULL;
	if( pChild ) 
		pLast = pChild->GetWindow(GW_HWNDLAST);

	if( !pChild )
		return NULL;
	do{
		
		GetClassName(pChild->GetSafeHwnd(), szClass, 200);	
		pChild->GetWindowText(strTitle);

		if(_tcsicmp(szClass, _T("Dialog")) == 0 )
		{
			
			HWND hChild = FindChildWindow(pChild, szClassName, szWindowTitle);
			if( hChild ) 
				return hChild;
		}
		pChild = pChild->GetWindow(GW_HWNDNEXT);

	}while( pChild && (pChild != pLast) );
	
	return NULL;
}

HWND FindChildWindow(CWnd * pParent, LPCTSTR szClassName, LPCTSTR szWindowTitle)
{
	ASSERT( szClassName || szWindowTitle );
	ASSERT( pParent );
	
	CString strTitle;
	TCHAR szClass[ 200 + 1] = {NULL};

	CWnd * pChild = pParent->GetWindow(GW_CHILD);
	ASSERT( pChild );
	CWnd * pLast = NULL;
	if( pChild )
		pLast = pChild->GetWindow(GW_HWNDLAST);

	if( !pChild )
		return NULL;

	do
	{
		GetClassName(pChild->GetSafeHwnd(), szClass, 200);
		pChild->GetWindowText(strTitle);

		if( (!szClassName || _tcsicmp(szClass, szClassName) == 0) 
		&&  (!szWindowTitle || strTitle.CompareNoCase(szWindowTitle) == 0) )
		{
			return pChild->GetSafeHwnd();
		}
			
		pChild = pChild->GetWindow(GW_HWNDNEXT);

	}while( pChild && (pChild != pLast) );

	return NULL;
}

Last question:
Is using FindWindow(_T("dialog"), <window title="">)
better than using FindWindow(_T("dialog"), <window title="">) ?
Does specifying the class name prevent it from using the sendmessage call internally for those cases where the window is obviously not a dialog?

Thanks! Any help would be swell.
Wes

David Crow11-Jun-04 7:24

11-Jun-04 7:24

Wes Jones wrote:
have an app that uses FindWindow to find the window handle to another app's window, and it looks like it is hanging.

You are correct about FindWindow()'s use of SendMessage() and the deadlock that can occur.

Wes Jones wrote:
My question is: What's a good alternative to using FindWindow ?

That all depends on what you are wanting to do.

Wes Jones wrote:
Last question:
Is using FindWindow(_T("dialog"), )
better than using FindWindow("dialog", ) ?

"Better" depends on if you are using Unicode or not. The _T() macro will work in either case as the preprocessor will resolve it accordingly.

Wes Jones wrote:
Does specifying the class name prevent it from using the sendmessage call internally for those cases where the window is obviously not a dialog?

What if two windows have the same class? FindWindow() is still no help.

"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen

Wes Jones11-Jun-04 7:52

11-Jun-04 7:52

Hi, thanks for the reply.

DavidCrow wrote:
That all depends on what you are wanting to do.
What I'm trying to do is...

I am writing an app on A CE device, and it uses a wireless modem to connect to the internet so that it can communicate w/ a server....

My code is trying to make it easy for the user by starting/stopping the modem software at the apprpriate times.

Before starting the modem, I look for the window titles for the various versions of the modem software that we support, and if it's already thereI won't start the modem software,
If I'm trying to close the modem, I try to get the handle to the window so that I can post the WM_CLOSE or appropriate messages to get the modem software to exit.
I support doing this for the Sierra Wireless AirCard 300, 555, 710, and 750 modems.

I wrote
Last question:
Is using FindWindow(_T("dialog"), )
better than using FindWindow("dialog", ) ?

Oops, meant to put the _T() macro on that last one there...

I guess my hope there is that I'd be cutting out of the equation any windows that aren't "dialog", even though it's not 100%.

I've found w/ Spy++ that some versions of the modem software creates two top level windows w/ the same title.... not ideal, but I've been getting around it.

Navin11-Jun-04 7:48

Navin

11-Jun-04 7:48

A better alternative - if you just want to communicate - is to use kernel objects. Take a look at some of the articles here on CP in the Threads and IPC section. I'm not sure which kernel objects CE supports, but hopefully that will put you in the right direction.

Now, this will only work if you own all processes/windows in question. If you don't... that is, you are looking for some system or 3rd party window, you are pretty much relegated to hacks, unless the apps in question have a published/well-defined way to communicate with them. By hacks I mean, using FindWindow and hardcoding the window text (bad idea becuase FindWindow can hang, and the window text could change.)

"Fish and guests stink in three days." - Benjamin Franlkin

Wes Jones11-Jun-04 8:00

11-Jun-04 8:00

Hi Navin,

Yeah, it's w/ a 3rd party app that I'm tryin to get at, and as it's my luck that there are no such well defined ways to doin it.

Something that could be of help.... is anyone aware of a way to test if a window will respond to SendMessage? Normally, SendMessageTimeout would allow me to figure out that the window isn't responding, and I would ignore it... but w/ CE that handy function isn't available. What's another way to know if it won't respond?

Thanks!

Navin11-Jun-04 8:04

Navin

11-Jun-04 8:04

And actually, it may be worse than just the problems you are seeing. If that 3rd party app is translated into any languages that you aren't (e.g., the dialog title will change), again you're screwed.

"Fish and guests stink in three days." - Benjamin Franlkin

Neville Franks11-Jun-04 11:40

Neville Franks

11-Jun-04 11:40

Can you accomplish what you need by enumerating the task/process list?

Neville Franks, Author of ED for Windows www.getsoft.com and coming soon: Surfulater www.surfulater.com

Wes Jones11-Jun-04 14:17

11-Jun-04 14:17

That would work (using the CreateToolhelp32Snapshot & APIs) for seeing if it's already running, but there are still cases where I'll need the window handle...

I think mix of that & using GetWindowThreadProcessId() might help me out.

Thanks!

Neville Franks11-Jun-04 15:17

Neville Franks

11-Jun-04 15:17

Wes Jones wrote:
That would work (using the CreateToolhelp32Snapshot & APIs) for seeing if it's already running, but there are still cases where I'll need the window handle...

If I recall correctly there are ways to get the main window handle for a process.

I've just bought my first PDA and am reasonably impressed. However I don't think I'll be doing any programming for it any time soon.;)

Neville Franks, Author of ED for Windows www.getsoft.com and coming soon: Surfulater www.surfulater.com

Microsoft !!! Q's

suiram4011-Jun-04 6:49

suiram40

11-Jun-04 6:49

1. How they can call a type(class name) CObject.
As long an object is an instance of a class,
How they can call a class 'CObject' ???

2. Extreme encapsulation!!!
-I've seen this in MFC/ATL implementations:
If they have C++ classes usually they make data members
private and provides public functions for access
Them as read/write (Set***(), Get***), so instead writing
obj.member=5; you write obj.SetMemebr(5); and
type t = obj.member; you write type t = obj.GetMember().
-On the other hand when you use some COM components type libraries
By default (!raw_interfaces_only) they wrap the ccom_ptr
In the *.tli generated files around the interfaces 'transforming'
The interface method calls (__declspace(propput=)...)
po->SetVar(type) into po->_var=type; which is the other way around.
So finally the cool thing is when we have the possibility of right member access we wrap function calls and when we have function calls
We wrap direct member access call. Isn’t this weird?
Smile | :)

Maximilien11-Jun-04 6:55

Maximilien

11-Jun-04 6:55

( is it a rant or a question ? )

suiram40 wrote:
1. How they can call a type(class name) CObject.

Why not ? I can call my base class CPotato if you want ...

suiram40 wrote:
2. Extreme encapsulation!!!

for the first part, Yeah, this is the way to do OO programming ( IMHO ), to privatize data members, and have setters and getters.

why ? because it's safer. clearer.

if for some reason, you decide to change the name of the variable; you will need to change it everywhere, with getter/setters, you only change the class.

Maximilien Lincourt
Your Head A Splode - Strong Bad

David Crow11-Jun-04 7:28

11-Jun-04 7:28

Maximilien wrote:
I can call my base class CPotato if you want ...

Yes, but would it be able to handle ketchup (for frenched fries), or butter (for mashed)? I like both styles so these accommodations are a requirement!!

"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen

Maximilien11-Jun-04 7:29

Maximilien

11-Jun-04 7:29

only if they are friend classes ... Big Grin | :-D

Maximilien Lincourt
Your Head A Splode - Strong Bad

suiram4011-Jun-04 7:39

suiram40

11-Jun-04 7:39

'CPotato' and any other specific category is right fine, but CObject ???

David Crow11-Jun-04 8:06

11-Jun-04 8:06

suiram40 wrote:
but CObject ???

Why not CObject? It is the least common denominator.

"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen

Henry miller11-Jun-04 8:03

Henry miller

11-Jun-04 8:03

For point two:

Imagine a simple circle class. You have setters and getters for Area, Radius, and Diameter. Simple grade school math gives the relation between them. Now which are you going to store in your class? If you use setters and getters it doesn't matter because you can change it at anytime without anyone else being affected. (and a good compiler will inline them so there isn't overhead)

Think it doesn't matter? Say you pick area. Well I'm going to use your class, but after a profiler I've discovered that getting the diameter is taking a large part of the CPU time, and the system is too slow. A simple change to the class to store diameter will speed things dramaticly. Of course if you anticipated area being most needed, then area would be right. (even though square roots are slower than powers in general)

Of course the example I gave is contrived. You should get the idea though. In the real world it often turns out that you don't know in advance what you will need to change latter so you use getters and setters everywhere just in case. 95% or more of the time you will never change it, but overall you have saved yourself a lot of work with the getters and setters.

jj3pa11-Jun-04 14:21

jj3pa

11-Jun-04 14:21

<snip>
1. How they can call a type(class name) CObject.
As long an object is an instance of a class,
How they can call a class 'CObject' ???

The idea is that all objects in MFC are based on it ... much as object in Java and C#

<snip>
2. Extreme encapsulation!!!
-I've seen this in MFC/ATL implementations:
If they have C++ classes usually they make data members
private and provides public functions for access
Them as read/write (Set***(), Get***), so instead writing
obj.member=5; you write obj.SetMemebr(5); and
type t = obj.member; you write type t = obj.GetMember().
-On the other hand when you use some COM components type libraries
By default (!raw_interfaces_only) they wrap the ccom_ptr
In the *.tli generated files around the interfaces 'transforming'
The interface method calls (__declspace(propput=)...)
po->SetVar(type) into po->_var=type; which is the other way around.
So finally the cool thing is when we have the possibility of right member access we wrap function calls and when we have function calls
We wrap direct member access call. Isn’t this weird?

As others have said its good style to have setters and getters, especially for setters ... Maybe you want a member to be restricted to 1..100 .. How would you do that otherwise ?

Maybe you have a member that constantly needs to be refreshed ... say the exchange rate for Euros to US Dollars. Just returning the current value stored would do no good, and constantly updating the value may be inefficent ... so just make sure you have the current value when you need it.

This is dealt with in other languages via properties ... getters and setters kinda hidden in the syntax.