C / C++ / MFC

Re: Check if a window is hidden by another window

3-Jan-12 5:57

Take a look at these functions:

GetNextWindow(), and GetForegroundWindow()

The difficult we do right away...
...the impossible takes slightly longer.

Randor 3-Jan-12 6:42

Randor

3-Jan-12 6:42

Hi,

You might be looking for the GetClipBox function[^].

How to tell if your window is completely hidden[^].

Best Wishes,
-David Delaune

Re: Check if a window is hidden by another window

Albert Holguin4-Jan-12 9:39

Albert Holguin

4-Jan-12 9:39

Do you really need to check if it's visible? ...If you need it to be in the forefront, why not just bring it to the front (use CWnd::SetWindowPos())?

Thread sync

columbos149272-Jan-12 20:05

columbos14927

2-Jan-12 20:05

Hey,
In my App i have one thread that grabs frames from a camera and paste them on the client window.
The client window belongs to the main thread of the App so when i try to resize it my App crushes.
I think it happens because the window is a mutual resource of the threads so what happens is that both access him at the same time.

how can i solve my problem?

Thanks

Randor 2-Jan-12 20:20

Randor

2-Jan-12 20:20

Hi,

Your question is not very well formed. You should consider revising it and give us an error code, and any other relevant information.

columbos14927 wrote:
In my App i have one thread that grabs frames from a camera and paste them on the client window.

Are you saying that you use Clipboard Operations[^] to paste an image? Are you sure about this?

columbos14927 wrote:
The client window belongs to the main thread of the App so when i try to resize it my App crushes.

I certainly hope your monitors are not being crushed as that would get expensive very fast. Smile | :)

I believe you mean crashes? If so... then you should have received an error code. When you ask for help from other software engineers... please give detailed information including any error code.

columbos14927 wrote:
I think it happens because the window is a mutual resource of the threads so what happens is that both access him at the same time.

Windows belong to a single thread. However if you attempt to access resources that belong to that thread from other threads... Yes, this can cause problems.

columbos14927 wrote:
how can i solve my problem?

I have no idea. I have no error code, no source code and no description of the application architecture.

Best Wishes,
-David Delaune

columbos149272-Jan-12 20:29

columbos14927

2-Jan-12 20:29

Hey,
1.The painting on the window is done by some function that is provided by frame grabber manufactorer.
I pass to this function the the handle to my window and the frame and then i call the "RedrawWindow" function.

2.When i resize the window the App freezes and not responding to anything there are no error codes.

Hope its more clear now...

Randor 2-Jan-12 21:01

Randor

2-Jan-12 21:01

Hi,

columbos14927 wrote:
1.The painting on the window is done by some function that is provided by frame grabber manufactorer.

Have you considered contacting the manufacturer?

columbos14927 wrote:
2.When i resize the window the App freezes and not responding to anything there are no error codes.

If you want to be a good software engineer then you will need to learn how to use your debugger.

When your application freezes:

1.) Execute a Debug build of your application from Visual Studio with debugger attached.
2.) Inside your Visual Studio you need to do a 'Break All'
3.) In Visual Studio make sure that Debug->Windows->Thread is visible. If you are a keyboard kind of guy this would be: CTRL+ALT+H
4.) In Visual Studio make sure that Debug->Windows->Callstack is visible. If you are a keyboard kind of guy this would be: CTRL+7
5.) Each thread is listed in the window along with the top of the callstack.
6.) You can select a thread in the Visual Studio debugger... and the 'CallStack' window will show the callstack associated with that thread.

Now you will be able to find what is causing the freeze.

Sometimes I find that WinDbg[^] is more powerful. If you want to use this then you would:

1.) Compile a Debug version of your application with Visual Studio.
2.) Download and install Debugging Tools for Windows[^]
3.) Launch your application from WinDbg or conversely... attach to the running instance.
4.) Wait for the freeze, or invoke it.
5.) When it freezes... Choose Debug->Break from the menu or from keyboard CTRL+BREAK
6.) Issue the command: !analyze -v -hang to have WinDbg analyze any hangs.
7.) Inspect the callstack of all threads and look for possible causes to the hang: ~*kv 250
8.) Another useful command is: !runaway[^] for having a look at thread times. Sometimes a hanging thread is spinning in an infinite loop and you can see which thread is hung... by observing that its consuming all of the thread times.
9.) If you still have not found it yet... it could be the main thread in a wait state... infinitely waiting to obtain a critical section or mutex... you can issue an !ntsdexts.locks[^] to look for critical sections and waiting threads.

If you are using WinDbg to debug a 32 bit executable under WOW64 then you might need to issue: .load wow64exts; .effmach x86

Someone should probably write and article or Tip/Trick about this.

Best Wishes,
-David Delaune

Bob Ciora4-Jan-12 1:06

Bob Ciora

4-Jan-12 1:06

Client area painting must occur in the main Windows thread. The problem is that the thread grabbing the frames is not the main Windows thread. So while it's drawing to the client area, any old windows message might come along and cause a crash as the two threads bump into each other. This is especially true when resizing - there are lots of "PAINT" messages hitting the dialog, and there's a good chance that PAINT handling is happening at the same time your other thread is drawing to the client area. Result is a crash.

The solution is to have the main windows thread do the drawing. So you'll need a way to move the frames from the grabber thread to the windows thread, and signal your dialog that it's time to draw a new frame.

You could try using a custom message, e.g. WM_USER+<n> ( see here: http://www.ucancode.net/Visual_C_MFC_Example/RegisterWindowMessage-WM_USER--VC-Example.htm[^] ). You can allocate a buffer to hold the frame and pass the pointer to that buffer as the LPARAM. The frame-grabber thread then just needs to PostMessage(...) to the Dialog.

On the Dialog side, add the handler for the WM_USER+<n> message to draw the image pointed to by LPARAM. Don't forget to deallocate that buffer when done!

This is just one example for moving information from some "outside" thread to the main windows thread. You can probably find many others.

- Bob

Bob Ciora

columbos149274-Jan-12 1:26

columbos14927

4-Jan-12 1:26

Thanks allot!!!!

JackDingler4-Jan-12 12:19

JackDingler

4-Jan-12 12:19

Another way to handle this may be to pause your camera app during dialog paint and resize functions.

Assuming the API allows this.

DLL Questions

Richard Andrew x642-Jan-12 17:19

2-Jan-12 17:19

Is there a function for determining the size of a DLL image as it is loaded into the process address space?

How do we determine the base address of a loaded DLL?

Also, is there some way to tell the system to load a DLL at a base address that I specify, regardless of the image's preferred base address?

The difficult we do right away...
...the impossible takes slightly longer.

Rajesh R Subramanian2-Jan-12 17:41

Rajesh R Subramanian

2-Jan-12 17:41

There's some good info on related topic in here: Hooks and DLLs[^]

"Real men drive manual transmission" - Rajesh.

Richard Andrew x642-Jan-12 17:45

2-Jan-12 17:45

Thanks. I'll check that out.

The difficult we do right away...
...the impossible takes slightly longer.

Randor 2-Jan-12 18:50

Randor

2-Jan-12 18:50

Hi Richard,

Richard Andrew x64 wrote:
How do we determine the base address of a loaded DLL?

The HMODULE that you get from the GetModuleHandle function[^] is the same as the base address. If you are writing MFC applications... this will be the same address returned from AfxGetResourceHandle [^]. The AfxGetInstanceHandle[^] function is actually returning the base address of the main application image.

If you are using a Microsoft compiler then you also have access to an extern variable __ImageBase which can be used to access the these base addresses. Because it is equal to an HMODULE you can also use this variable for loading resources[^].

Now that we have the base address we can read the PE image headers [^]and check for a size:

C++

DWORD GetSizeOfImage(HMODULE hModule)
{
	DWORD dwSize = 0;
	PIMAGE_DOS_HEADER pDOSHeader = (PIMAGE_DOS_HEADER)hModule;
	PIMAGE_NT_HEADERS pNTHeader = (PIMAGE_NT_HEADERS)((PBYTE)hModule + pDOSHeader->e_lfanew);
	if(IMAGE_NT_SIGNATURE == pNTHeader->Signature)
	{
		PIMAGE_FILE_HEADER pFileHeader = (PIMAGE_FILE_HEADER)((PBYTE)&pNTHeader->FileHeader);
		PIMAGE_OPTIONAL_HEADER pOptionalHeader = (PIMAGE_OPTIONAL_HEADER)((PBYTE)&pNTHeader->OptionalHeader);
		if(IMAGE_NT_OPTIONAL_HDR32_MAGIC ==  pNTHeader->OptionalHeader.Magic)
		{
			dwSize = pNTHeader->OptionalHeader.SizeOfImage;
		}
	}
	return dwSize;
}

Richard Andrew x64 wrote:
Also, is there some way to tell the system to load a DLL at a base address that I specify, regardless of the image's preferred base address?

Maybe... check out the /FIXED (Fixed Base Address)[^] linker option.

I consider fixed base addresses to be an insecure option... I highly recommend that all software engineers support a dynamic base address.

PE images with support for ASLR[^] will have the IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE bit set in the PE image characteristics. These modules are essentially saying 'put me anywhere you want... I don't care' and the kernel pseudo-randomly chooses an address to map the image.

PE images without support for ASLR... the NT kernel will make an attempt to load the image at its preferred address at pNTHeader->OptionalHeader.ImageBase. If the address is already allocated the kernel will make an attempt to map the image at another address and apply its fixups.

Best Wishes,
-David Delaune

Richard Andrew x642-Jan-12 18:57

2-Jan-12 18:57

Thanks for a terrific reply. I certainly appreciate the info!

The difficult we do right away...
...the impossible takes slightly longer.