C / C++ / MFC

Both EnumchildWindows and GetWindow return NULL for a ChildWindow modeless dialogbox

16-Mar-16 15:45

Well,
I Know very little about Java, and this is an MFC/CPP Forum. In CPP a default argument is declared in the function declaration in a class, as in

C++

class CMyClass{ int MyFunct(int Arg=0);};

This is a Declaration that MyClass has a Method named'MyFunct', which returns an int, and Optionally takes a Parameter (Arg),
and, that when I call this function without a parameter, that 0 will be assumed. You make those declarations in a 'Header File'

You Implement the function in the Implementation File,(Typically a CPP File) were you actually Implement the function:

C++

int MyClass::MyFunct(int Arg)
if(Arg==0)return 1;
else return 2;
}

The above means that when using the class, you write:

C++

MyClass myclass;// Instantiate the class.
myclass.MyFunct();//Will return 1, an Argument 0 is assumed
myclass.MyFunct(0);// will return 1, the Argument 0 is specified
myclass.MyFunct(12);//returns 2, as per Calculation, Arg !-0

Your Marshalling Software beteween Java and CPP should give more details.

Smile | :)

Bram van Kampen

ForNow10-Mar-16 10:19

Re: Both EnumchildWindows and GetWindow return NULL for a ChildWindow modeless dialogbox

10-Mar-16 10:19

Hi,

I have a console application that spawns a childprocess

I am initially able to get the MainFrame Window in the console app thru EnumThreadWindows

Later I create a modeless Dialog in the childprocess for which I would like the to get the HWND handle

I am running this code (both apps) under the Visual Studio debugger

So I can see when the child process creates the modeless dialogbox

I then step thru (under VS debugger) both GetWindow(MainFrame,GW_CHILD) and EnumChildWindows

and neither API return anything

Bram van Kampen10-Mar-16 14:39

Re: Both EnumchildWindows and GetWindow return NULL for a ChildWindow modeless dialogbox

10-Mar-16 14:39

What on Earth are you trying to Achieve!

Writing a Console Program trying to spawn an MFC Wnd App is not really possible, or desirable!
The only practical way this is possible is by the Console Program calling the Standard 'C' 'system(...)' function to launch the Windows App.
If you are looking for tooling to restart a misbehaving Windows Program, you came to the right door. I have just that.
The actual code is proprietary, but I can explain how it works.

Regards,

Bram. Smile | :)

Bram van Kampen

ForNow10-Mar-16 15:20

Re: Both EnumchildWindows and GetWindow return NULL for a ChildWindow modeless dialogbox

10-Mar-16 15:20

First of I apologize maybe I should spent more time looking up critical section

As all it is thread synchronization

I am a MainFrame assembler programmer by trade and was trying to learn new technology

I picked windows I wrote a front end for this C console program originally the code

was C then I re-wrote it in MFC C++ I am sure a more experienced C++ programmer could

have done a better job. But this was my way of learning

I created the Windows MFC C++ program with CreateProcess

Richard MacCutchan11-Mar-16 3:52

Re: Both EnumchildWindows and GetWindow return NULL for a ChildWindow modeless dialogbox

11-Mar-16 3:52

ForNow wrote:
I ended up having the debugging modeless dialog box HWND being returned to me from the SendMessage to the main window as both LRESULT and HWND are both 64 bits wide running 64 bit mode as I don't want the console program to sit around and wait for a response (and hold it up) I do a PostMessage from the console program
Thanks

I (like Bram) am confused as to what you are trying to do here. Or indeed what your point is of using a console application to launch a Windows application, to launch a modeless dialog.

Richard MacCutchan10-Mar-16 21:21

Re: Both EnumchildWindows and GetWindow return NULL for a ChildWindow modeless dialogbox

10-Mar-16 21:21

Without sight of your code it is anyone's guess what you are doing wrong.

leon de boer19-Mar-16 21:50

leon de boer

19-Mar-16 21:50

I have three suggestion/comments:

1.) You said quote: "Later I create a modeless Dialog in the childprocess for which I would like the to get the HWND handle."

Doesn't matter which create method you use you get the handle back right then ... so why don't you hold it??????

2.) Like others I wonder why you are using MFC at all which will be problematic why would you not just use the WIN32 API.

3.) If GetWindow(MainFrame,GW_CHILD) and EnumChildWindows are returning false the your created window isn't parented
to the window at all. It's most likely parented to the desktop and again go back to number 1 above show us the how
you created the modeless dialog and check you gave it a parent.

The key point here is a show use the lines of code around the modeless dialog creation call.

In vino veritas

Re: Both EnumchildWindows and GetWindow return NULL for a ChildWindow modeless dialogbox

ForNow20-Mar-16 12:45

How Much of WM_USER+X is used by MFC

20-Mar-16 12:45

I did use GetWindow and got NULL. I was able to get Window Handle by doing a SendMessage to the other app as the return Value is From the other Window App (not Windows like PostMessage) I returned the dialog window in LRESULT

Thanks

Bram van Kampen9-Mar-16 14:14

9-Mar-16 14:14

Well,

Using MFC, in a multithreaded environment, communication via SendMessage(...) is an essential.
Trying to sculpt WDK Messages for my own purpose. Use WM_USER+x, Major Crash,turned out, WM_USER+x was already used by MFC42 in a control I used in my Dialog!
has Anyone any idea what the range of messages are used or reserved by MFC in general, and what the Real Message range is, available to MFC developers.

C++

++"#define WM_MFC_USERS 0xABXD1234

Or, something of that kind in some header somewhere. If this is the case, please let me know the Name and the value of the macro is.

Regards Smile | :)

Bram van Kampen

Jochen Arndt9-Mar-16 21:38

Jochen Arndt

9-Mar-16 21:38

WM_USER is obsolete. Use WM_APP instead. Or better use registered messages.

A good description about this topic can be found in the CodeProject article Message Management[^].

Richard MacCutchan9-Mar-16 22:17

9-Mar-16 22:17

WM_USER+x should only ever be used inside a single application, as it is free to use by everyone. Using it in a driver is almost bound to cause tears before bedtime.

[edit]
WM_USER (Windows)[^] and WM_APP (Windows)[^] list the rules.
[/edit]

Bram van Kampen10-Mar-16 14:03

10-Mar-16 14:03

Thanks,

I am aware of RegisterMessage(...) etc, but have always considered it as a canon to shoot a fly. It may be the better Idea for future, particularly after the nightmare I encounter now. Your idea of attaching a GUID is particularly fetching.
WM_USER +X, It worked for me many a time in the past. I can now see the flaws

Thanks,

Bram. Smile | :)

Bram van Kampen

Richard MacCutchan10-Mar-16 21:15

10-Mar-16 21:15

Jochen Arndt10-Mar-16 21:38

Jochen Arndt

10-Mar-16 21:38

It looks like a reply to my answer posted to yours inadvertently.

Richard MacCutchan10-Mar-16 21:50

10-Mar-16 21:50

I don't know what Bram is smoking these days, but I think he should cut down. Wink | ;)

Bram van Kampen10-Mar-16 14:08

10-Mar-16 14:08

Hi,

Good to talk again.

My header files do not provide a macro for WM_APP. Maybe you could let me know for future reference, if it is a single value. Also AOP has advised me to Register a Windows Message. Probably the way forward for the Future.

Thanks for your contribution.

Bram. Smile | :)

Bram van Kampen

Ensuring code runs synchronously

Victor Nijegorodov11-Mar-16 3:17

Victor Nijegorodov

11-Mar-16 3:17

WM_APP (Windows)[^]

ForNow9-Mar-16 4:01

Re: Ensuring code runs synchronously

9-Mar-16 4:01

Is a crtical section a way of ensuring the your code runs synchrounsly as window message processing seems to take precedence in code execution

Richard MacCutchan9-Mar-16 6:21

Re: Ensuring code runs synchronously

9-Mar-16 6:21

It ensures only one thread can go through that code path: see Critical Section Objects (Windows)[^].

ForNow wrote:
window message processing seems to take precedence

Not sure what you mean by that.

Bram van Kampen9-Mar-16 14:29

Re: Ensuring code runs synchronously

9-Mar-16 14:29

In Short, No!

Critical Sections are Synchronisation Objects, It is of use only if your project is multi threaded,ie Has More than One thread running in the One Program. Each thread of your program, will wait in front of a CriticalSection where you try to Enter It, until all other threads leave it. It is a communal comunication deal between threads in a program. One thread of a program will not allow another thread to run, until the section is released. Other programs can switch thread in the mean time.

The Nature and context of the question worries me! You seem to have to learn an awfull lot more before you are ready to discus critical sections

Smile | :)

Bram van Kampen

Bram van Kampen9-Mar-16 15:04

Non display characters for selection count

9-Mar-16 15:04

No,
It is NOT, and I explained that already!
However, I also answered your other question, in quite a lot of detail. Before you can attempt to learn MFC Multi Threaded Programming, you will need to learn basic MFC Programming, and elements of the Windows SDK. MFC is a thin wrapper around the Windows SDK. Sometimes you need the real thing! Definitely needed in Multithreading.

Cannot Help it, You need to study more before we can help you.

Bram

Bram van Kampen

ForNow8-Mar-16 19:44

Re: Non display characters for selection count

8-Mar-16 19:44

Hi

I have 3 rows of text in my rich edit.
At the end of each line I move a carriage return line feed, to force a new line
/r/n. Do these 2 bytes count as 2 characters when determining the count for the selection

Thanks

Richard MacCutchan8-Mar-16 21:45

Re: Non display characters for selection count

8-Mar-16 21:45

The documentation at EM_GETSELTEXT message (Windows)[^] does not explicitly say whether it does, or does not. But a simple test should prove it one way or another.

ForNow9-Mar-16 3:55