C / C++ / MFC

Re: Convert CString to CObject VC 6.0 MFC

3-Jan-12 8:49

Good one, I like your KISS approach.
Thanks

ThatsAlok3-Jan-12 19:16

ThatsAlok

3-Jan-12 19:16

agreed, like your KISS approach!

"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture

cheers,
Alok Gupta
VC Forum Q&A :- I/IV
Support CRY- Child Relief and You

Check if a window is hidden by another window

Member 29654713-Jan-12 5:48

Member 2965471

3-Jan-12 5:48

Hi all, how can I check if window is hidden by another window?

I tried IsWindowVisible but doesn't work.

Re: Check if a window is hidden by another window

Richard Andrew x643-Jan-12 5:57

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.

How to modify hardware's property via win32 API

Randor 2-Jan-12 19:13

Randor

2-Jan-12 19:13

Hey,

Your very welcome. I just happened to be researching ASLR very recently while developing a device driver for extending the NEMET security application[^].

In case I did not answer your second question very clearly... no you cannot make the NT loader map a module to an arbitrary address other than the preferred address... it will choose the address itself. You *could* however manually map the module yourself using a technique similar to what was described ages ago... by Joachim Bauch.

Best Wishes,
-David Delaune

freshtiny2-Jan-12 16:17

freshtiny

2-Jan-12 16:17

Hello guys,

I met a trouble when i try to modify a hardware's property via API.

It's a USB2COM which is able to perform high-baudrate serial communication. Cause i hope it could update data within 1ms, i have to modify the its update property(latency-timer) from 16ms(default) to 1ms.

Of course i could do that with
[My computer -> System property -> Hardware -> Device Manager ... ], just like the steps described in the following setting manual.

Here is a setting manual, USB2COM Setting Manual. There is the detail description about latency-timer setting, @ Page16 3.3.2.1 .

But i want to know if there is may be another more elegant method via API in shell32.dll or user32.dll?

Control_RunDLL in shell32.dll brings me little help, cause it could do nothing more than shell("Control.exe sysdm.cpl ,2"). What i want is a methed can just modify the number from 16 to 1...

USB2COM's drivers couldnt help me, either, cause no documentation or interface is given.

Could someone give me some advice? I'll be very appreciated.

Thanks.

Re: How to modify hardware's property via win32 API

Vaclav_2-Jan-12 17:04

Re: How to modify hardware's property via win32 API

2-Jan-12 17:04

Unless you are comfortable working with EIA / RS232 / COM hardware , this can get scarry.
What you need is to get to <b>DCB - data communication block</b> and than you can manipulate most, and I stress most, of the COM paramaters. There are articles about COM in here, but they usually do not explain what is happening in hardware when it comes to working with COM.

freshtiny2-Jan-12 21:05

freshtiny

2-Jan-12 21:05

Thanks a lot. Vaclav_Sal
My problem has been solved.

I found the setting interface(in ftd2xx.dll) from FTDI knowledge base.

Dynamic array of afx_msg functions - using CPtrArray ( MFC VC 6.0)

Vaclav_2-Jan-12 15:56

Re: Dynamic array of afx_msg functions - using CPtrArray ( MFC VC 6.0)

2-Jan-12 15:56

I am looking for a way to have a dynamic ( run time) array of afx_msg functions.
I have tried this with some success.
CPtrArray pArray;
pArray.Add((void*) OnFunctionkeysCallsate());
pArray.Add((void*) OnWindowNewlogview());
int iTest = pArray.GetSize();
iTest = pArray.GetUpperBound();
void * pElement = pArray.GetAt(0);
void * pElement_1 = pArray.GetAt(1);
Here are my problems
1. The GetSize returns 2 but GetAt(0) and GetAt (1) return same pointer. Why?
2. The Add method adds the function to the pointer array just fine but also runs it. I can live with that but like to know why it does that.
3. I have no clue what GetAt actually returns and how to use it.
4. I realize this approach still does not provide for dynamic add of a function. Working on that – I guess passing function as variable documentation should help.
5. Is it really “legal” to change the afx_msg function from void to void * as I did?
Thanks for your help. It is really appreciated.
Have a great 2012.
Vaclav

Chuck O'Toole2-Jan-12 16:01

Chuck O'Toole

2-Jan-12 16:01

pArray.Add((void*) OnFunctionkeysCallsate());

Calls the OnFunctionkeysCallsate() function and stores the result of that call into pArray. If I understand you correctly, this is not what you want. Instead, you want the address of the function, not the result of invoking the function. Remove the "()".

Re: Dynamic array of afx_msg functions - using CPtrArray ( MFC VC 6.0)

Vaclav_2-Jan-12 16:39