By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,967 Members | 815 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,967 IT Pros & Developers. It's quick & easy.

CreateDialogIndirect() fires Radio button click function .....

P: n/a
CreateDialogIndirect() fires my Radio button click function without the radio
button having being clicked. I am using VC++ 2003.NET. I believe this is yet
another Microsoft bug. Have checked dialog resources and memory - both appear
to be in order. Can anyone comment on this? Should CreateDialogIndirect()
which is located in dlgcore.cpp ever fire a button click routine??
Jan 17 '06 #1
Share this Question
Share on Google+
24 Replies


P: n/a
"John Gabriel" <Jo*********@discussions.microsoft.com> wrote in message
news:CC**********************************@microsof t.com...
CreateDialogIndirect() fires my Radio button click function without the
radio
button having being clicked. I am using VC++ 2003.NET. I believe this is
yet
another Microsoft bug.


Hmm. Usually bugs in the o/s affect thousands of developers / users. And
when they do, there is usually a knowledge base article or other discussion
of it easiliy retrievable with a Google search. I just looked and found
nothing.

I'm not saying there isn't one (I don't have enough information to make that
assertion) but I'm skeptical. If you can whittle the problem down to a small
example and post it here, someone may have better advice for you.

Regards,
Will
Jan 17 '06 #2

P: n/a
You are mistaken to think the way you do. I have found hundreds of bugs in
Microsoft products and I am not so sure these affect thousands of developers.

Let's see if I can clarify this a bit more:

"William DePalo [MVP VC++]" wrote:
"John Gabriel" <Jo*********@discussions.microsoft.com> wrote in message
news:CC**********************************@microsof t.com...
CreateDialogIndirect() fires my Radio button click function without the
radio
button having being clicked. I am using VC++ 2003.NET. I believe this is
yet
another Microsoft bug.


Hmm. Usually bugs in the o/s affect thousands of developers / users. And
when they do, there is usually a knowledge base article or other discussion
of it easiliy retrievable with a Google search. I just looked and found
nothing.

I'm not saying there isn't one (I don't have enough information to make that
assertion) but I'm skeptical. If you can whittle the problem down to a small
example and post it here, someone may have better advice for you.

Regards,
Will

Jan 17 '06 #3

P: n/a
I have no interest in debugging Microsoft products. In fact I have already
found a workaround but I will prove to you that this is a bug. I am an expert
assembly language programmer.

Let's see if I can clarify this a bit more:

CreateDialogIndirect is really a macro that wraps the
CreateDialogIndirectParam() function.

When I set a break point and disassembled the code, the following is what I
got:

hWnd = ::CreateDialogIndirect(hInst, lpDialogTemplate,
pParentWnd->GetSafeHwnd(), AfxDlgProc);
7C2364D0 mov ecx,dword ptr [pParentWnd]
7C2364D3 call CWnd::GetSafeHwnd (7C28E080h)
7C2364D8 mov dword ptr [ebp-94h],eax
7C2364DE push 0
7C2364E0 push offset AfxDlgProc (7C235B30h)
7C2364E5 mov edx,dword ptr [ebp-94h]
7C2364EB push edx
7C2364EC mov eax,dword ptr [lpDialogTemplate]
7C2364EF push eax
7C2364F0 mov ecx,dword ptr [hInst]
7C2364F3 push ecx
7C2364F4 call dword ptr [__imp__CreateDialogIndirectParamA@20
(7C141A98h)]
7C2364FA mov dword ptr [hWnd],eax

Notice the call to CreateDialofIndirectParam - my radio button click
function is fired from this call. There is nothing to wonder about here my
friend. This function should not be firing any button click functions.
Incidentally, it only fires one radio button click function and there are
more on that dialog.

John
"William DePalo [MVP VC++]" wrote:
"John Gabriel" <Jo*********@discussions.microsoft.com> wrote in message
news:CC**********************************@microsof t.com...
CreateDialogIndirect() fires my Radio button click function without the
radio
button having being clicked. I am using VC++ 2003.NET. I believe this is
yet
another Microsoft bug.


Hmm. Usually bugs in the o/s affect thousands of developers / users. And
when they do, there is usually a knowledge base article or other discussion
of it easiliy retrievable with a Google search. I just looked and found
nothing.

I'm not saying there isn't one (I don't have enough information to make that
assertion) but I'm skeptical. If you can whittle the problem down to a small
example and post it here, someone may have better advice for you.

Regards,
Will

Jan 17 '06 #4

P: n/a
Information for you to try and replicate the problem:

I am using MDI to create a view with a tab control. One of the tabs is the
home of several radio check buttons. All the radio check buttons have
click-event routines.
The function I referred to below only fires the first in the series of these
dialog radio buttons.

"John Gabriel" wrote:
I have no interest in debugging Microsoft products. In fact I have already
found a workaround but I will prove to you that this is a bug. I am an expert
assembly language programmer.

Let's see if I can clarify this a bit more:

CreateDialogIndirect is really a macro that wraps the
CreateDialogIndirectParam() function.

When I set a break point and disassembled the code, the following is what I
got:

hWnd = ::CreateDialogIndirect(hInst, lpDialogTemplate,
pParentWnd->GetSafeHwnd(), AfxDlgProc);
7C2364D0 mov ecx,dword ptr [pParentWnd]
7C2364D3 call CWnd::GetSafeHwnd (7C28E080h)
7C2364D8 mov dword ptr [ebp-94h],eax
7C2364DE push 0
7C2364E0 push offset AfxDlgProc (7C235B30h)
7C2364E5 mov edx,dword ptr [ebp-94h]
7C2364EB push edx
7C2364EC mov eax,dword ptr [lpDialogTemplate]
7C2364EF push eax
7C2364F0 mov ecx,dword ptr [hInst]
7C2364F3 push ecx
7C2364F4 call dword ptr [__imp__CreateDialogIndirectParamA@20
(7C141A98h)]
7C2364FA mov dword ptr [hWnd],eax

Notice the call to CreateDialofIndirectParam - my radio button click
function is fired from this call. There is nothing to wonder about here my
friend. This function should not be firing any button click functions.
Incidentally, it only fires one radio button click function and there are
more on that dialog.

John
"William DePalo [MVP VC++]" wrote:
"John Gabriel" <Jo*********@discussions.microsoft.com> wrote in message
news:CC**********************************@microsof t.com...
CreateDialogIndirect() fires my Radio button click function without the
radio
button having being clicked. I am using VC++ 2003.NET. I believe this is
yet
another Microsoft bug.


Hmm. Usually bugs in the o/s affect thousands of developers / users. And
when they do, there is usually a knowledge base article or other discussion
of it easiliy retrievable with a Google search. I just looked and found
nothing.

I'm not saying there isn't one (I don't have enough information to make that
assertion) but I'm skeptical. If you can whittle the problem down to a small
example and post it here, someone may have better advice for you.

Regards,
Will

Jan 17 '06 #5

P: n/a
"John Gabriel" <Jo*********@discussions.microsoft.com> wrote in message
news:F5**********************************@microsof t.com...
I have no interest in debugging Microsoft products.
OK.
In fact I have already found a workaround but I will prove
to you that this is a bug. I am an expert
assembly language programmer.
An assertion is not proof.
Let's see if I can clarify this a bit more:

CreateDialogIndirect is really a macro that wraps the
CreateDialogIndirectParam() function.
Correct.
When I set a break point and disassembled the code, the following is what
I
got:

hWnd = ::CreateDialogIndirect(hInst, lpDialogTemplate,
pParentWnd->GetSafeHwnd(), AfxDlgProc);
7C2364D0 mov ecx,dword ptr [pParentWnd]
7C2364D3 call CWnd::GetSafeHwnd (7C28E080h)
7C2364D8 mov dword ptr [ebp-94h],eax
7C2364DE push 0
7C2364E0 push offset AfxDlgProc (7C235B30h)
7C2364E5 mov edx,dword ptr [ebp-94h]
7C2364EB push edx
7C2364EC mov eax,dword ptr [lpDialogTemplate]
7C2364EF push eax
7C2364F0 mov ecx,dword ptr [hInst]
7C2364F3 push ecx
7C2364F4 call dword ptr [__imp__CreateDialogIndirectParamA@20
(7C141A98h)]
7C2364FA mov dword ptr [hWnd],eax

Notice the call to CreateDialofIndirectParam - my radio button click
function is fired from this call.


As I said, an assertion is not proof. There may be a bug there. But unless
you can say do X and Y results, and until that experience is replicated by
others, what we have here is just a little annecdote.

I just checked an application of mine (~50K lines of Win32 C code) in which
there is a single CreateDialogIndirect() call. I ran it on this XP/SP2 box.
I see no spurrious button clicks.

Look, I'm not saying there are no bugs in the platform. The knowledge base
lists quite a few. But in the ten years that I have been reading this group
and its predecessor on CIS, the overwhelming majority of new reports turn
out to be in the application code.

Regards,
Will
Jan 17 '06 #6

P: n/a
"John Gabriel" <Jo*********@discussions.microsoft.com> wrote in message
news:9F**********************************@microsof t.com...
Information for you to try and replicate the problem:
...
When I set a break point and disassembled the code, the following is what
I
got:

hWnd = ::CreateDialogIndirect(hInst, lpDialogTemplate,
pParentWnd->GetSafeHwnd(), AfxDlgProc);
7C2364D0 mov ecx,dword ptr [pParentWnd]
7C2364D3 call CWnd::GetSafeHwnd (7C28E080h)
7C2364D8 mov dword ptr [ebp-94h],eax
7C2364DE push 0
7C2364E0 push offset AfxDlgProc (7C235B30h)
7C2364E5 mov edx,dword ptr [ebp-94h]
7C2364EB push edx
7C2364EC mov eax,dword ptr [lpDialogTemplate]
7C2364EF push eax
7C2364F0 mov ecx,dword ptr [hInst]
7C2364F3 push ecx
7C2364F4 call dword ptr [__imp__CreateDialogIndirectParamA@20
(7C141A98h)]
7C2364FA mov dword ptr [hWnd],eax

Notice the call to CreateDialofIndirectParam - my radio button click
function is fired from this call.


I forgot to ask in my last post if you know that dialog creations causes the
WM_INITDIALOG message to sent? It is possible that whatever trouble you have
emanates from the handler for that message.

Regards,
Will
Jan 17 '06 #7

P: n/a
My first response is always to check my code for errors. I have been a
programmer over 20 years so I don't rush to conclusions and usually I am not
wrong. This is often perceived as arrogance but it is not - only quiet
confidence.

Look, this is not an assertion as you claim. Do you agree that the
CreateDialogIndirectParm() function should not fire click events? If you
answer yes to this, then there is a bug.

As I said, this function is called for a dialog box that is attached to a
Tab Control that is attached to 1 of 3 panes in a view. On this dialog box
there are only radio check buttons and all of them have a button click
routine.

I am using XP/SP1. But this makes no difference. I traced the call in
assembly right up to the point where my click routine is called. To me this
is solid proof that the CreateDialogIndirectParm function is firing my click
routine.

John

"William DePalo [MVP VC++]" wrote:
"John Gabriel" <Jo*********@discussions.microsoft.com> wrote in message
news:F5**********************************@microsof t.com...
I have no interest in debugging Microsoft products.


OK.
In fact I have already found a workaround but I will prove
to you that this is a bug. I am an expert
assembly language programmer.


An assertion is not proof.
Let's see if I can clarify this a bit more:

CreateDialogIndirect is really a macro that wraps the
CreateDialogIndirectParam() function.


Correct.
When I set a break point and disassembled the code, the following is what
I
got:

hWnd = ::CreateDialogIndirect(hInst, lpDialogTemplate,
pParentWnd->GetSafeHwnd(), AfxDlgProc);
7C2364D0 mov ecx,dword ptr [pParentWnd]
7C2364D3 call CWnd::GetSafeHwnd (7C28E080h)
7C2364D8 mov dword ptr [ebp-94h],eax
7C2364DE push 0
7C2364E0 push offset AfxDlgProc (7C235B30h)
7C2364E5 mov edx,dword ptr [ebp-94h]
7C2364EB push edx
7C2364EC mov eax,dword ptr [lpDialogTemplate]
7C2364EF push eax
7C2364F0 mov ecx,dword ptr [hInst]
7C2364F3 push ecx
7C2364F4 call dword ptr [__imp__CreateDialogIndirectParamA@20
(7C141A98h)]
7C2364FA mov dword ptr [hWnd],eax

Notice the call to CreateDialofIndirectParam - my radio button click
function is fired from this call.


As I said, an assertion is not proof. There may be a bug there. But unless
you can say do X and Y results, and until that experience is replicated by
others, what we have here is just a little annecdote.

I just checked an application of mine (~50K lines of Win32 C code) in which
there is a single CreateDialogIndirect() call. I ran it on this XP/SP2 box.
I see no spurrious button clicks.

Look, I'm not saying there are no bugs in the platform. The knowledge base
lists quite a few. But in the ten years that I have been reading this group
and its predecessor on CIS, the overwhelming majority of new reports turn
out to be in the application code.

Regards,
Will

Jan 17 '06 #8

P: n/a
"John Gabriel" <Jo*********@discussions.microsoft.com> wrote in message
news:EF**********************************@microsof t.com...
I am using XP/SP1. But this makes no difference. I traced the call in
assembly right up to the point where my click routine is called. To me
this
is solid proof that the CreateDialogIndirectParm function is firing my
click
routine.


As I said, it does not prove your assertion. You say CreateDialogIndirect()
is buggy in your experience. I say it is not in mine. What does that prove?
Absolutely nothing.

Further, there are a number of things that happen as a result of the call to
CreateDialogIndirect() and indeed happen _before_ it returns. For example,
more than a couple of messages are directed at the window as a result of the
call. The application's handler for any of them, or a handler in a base
class if you are using MFC or some such could be the source of your problem.

Regards,
Will
Jan 17 '06 #9

P: n/a
Not sure it applies, but radio buttons are documented to fire a BN_CLICKED
notification when they get a WM_SETFOCUS.
--
Jeff Partch [VC++ MVP]
"John Gabriel" <Jo*********@discussions.microsoft.com> wrote in message
news:EF**********************************@microsof t.com...
My first response is always to check my code for errors. I have been a
programmer over 20 years so I don't rush to conclusions and usually I am
not
wrong. This is often perceived as arrogance but it is not - only quiet
confidence.

Look, this is not an assertion as you claim. Do you agree that the
CreateDialogIndirectParm() function should not fire click events? If you
answer yes to this, then there is a bug.

As I said, this function is called for a dialog box that is attached to a
Tab Control that is attached to 1 of 3 panes in a view. On this dialog box
there are only radio check buttons and all of them have a button click
routine.

I am using XP/SP1. But this makes no difference. I traced the call in
assembly right up to the point where my click routine is called. To me
this
is solid proof that the CreateDialogIndirectParm function is firing my
click
routine.

John

"William DePalo [MVP VC++]" wrote:
"John Gabriel" <Jo*********@discussions.microsoft.com> wrote in message
news:F5**********************************@microsof t.com...
>I have no interest in debugging Microsoft products.


OK.
> In fact I have already found a workaround but I will prove
> to you that this is a bug. I am an expert
> assembly language programmer.


An assertion is not proof.
> Let's see if I can clarify this a bit more:
>
> CreateDialogIndirect is really a macro that wraps the
> CreateDialogIndirectParam() function.


Correct.
> When I set a break point and disassembled the code, the following is
> what
> I
> got:
>
> hWnd = ::CreateDialogIndirect(hInst, lpDialogTemplate,
> pParentWnd->GetSafeHwnd(), AfxDlgProc);
> 7C2364D0 mov ecx,dword ptr [pParentWnd]
> 7C2364D3 call CWnd::GetSafeHwnd (7C28E080h)
> 7C2364D8 mov dword ptr [ebp-94h],eax
> 7C2364DE push 0
> 7C2364E0 push offset AfxDlgProc (7C235B30h)
> 7C2364E5 mov edx,dword ptr [ebp-94h]
> 7C2364EB push edx
> 7C2364EC mov eax,dword ptr [lpDialogTemplate]
> 7C2364EF push eax
> 7C2364F0 mov ecx,dword ptr [hInst]
> 7C2364F3 push ecx
> 7C2364F4 call dword ptr [__imp__CreateDialogIndirectParamA@20
> (7C141A98h)]
> 7C2364FA mov dword ptr [hWnd],eax
>
> Notice the call to CreateDialofIndirectParam - my radio button click
> function is fired from this call.


As I said, an assertion is not proof. There may be a bug there. But
unless
you can say do X and Y results, and until that experience is replicated
by
others, what we have here is just a little annecdote.

I just checked an application of mine (~50K lines of Win32 C code) in
which
there is a single CreateDialogIndirect() call. I ran it on this XP/SP2
box.
I see no spurrious button clicks.

Look, I'm not saying there are no bugs in the platform. The knowledge
base
lists quite a few. But in the ten years that I have been reading this
group
and its predecessor on CIS, the overwhelming majority of new reports turn
out to be in the application code.

Regards,
Will

Jan 17 '06 #10

P: n/a
Jeff,

Looks like it might very well apply. All this happens in the
CreateDialogIndirectParam() routine. So if there is a WM_SETFOCUS being sent,
I don't do it anywhere in my code. It still seems illogical (to me) that the
BN_CLICKED notification is fired when a WM_SETFOCUS message is received
(unless that WM_SETFOCUS is caused by an 'actual' mouse click). As this
happens in the creation routine, no mouse button has been clicked and so no
BN_CLICKED notification should be sent.

I tried changing the radio control properties so that no tab stop generates
a WM_SETFOCUS but the mouse click notificatioin is still generated.

John

"Jeff Partch [MVP]" wrote:
Not sure it applies, but radio buttons are documented to fire a BN_CLICKED
notification when they get a WM_SETFOCUS.
--
Jeff Partch [VC++ MVP]
"John Gabriel" <Jo*********@discussions.microsoft.com> wrote in message
news:EF**********************************@microsof t.com...
My first response is always to check my code for errors. I have been a
programmer over 20 years so I don't rush to conclusions and usually I am
not
wrong. This is often perceived as arrogance but it is not - only quiet
confidence.

Look, this is not an assertion as you claim. Do you agree that the
CreateDialogIndirectParm() function should not fire click events? If you
answer yes to this, then there is a bug.

As I said, this function is called for a dialog box that is attached to a
Tab Control that is attached to 1 of 3 panes in a view. On this dialog box
there are only radio check buttons and all of them have a button click
routine.

I am using XP/SP1. But this makes no difference. I traced the call in
assembly right up to the point where my click routine is called. To me
this
is solid proof that the CreateDialogIndirectParm function is firing my
click
routine.

John

"William DePalo [MVP VC++]" wrote:
"John Gabriel" <Jo*********@discussions.microsoft.com> wrote in message
news:F5**********************************@microsof t.com...
>I have no interest in debugging Microsoft products.

OK.

> In fact I have already found a workaround but I will prove
> to you that this is a bug. I am an expert
> assembly language programmer.

An assertion is not proof.

> Let's see if I can clarify this a bit more:
>
> CreateDialogIndirect is really a macro that wraps the
> CreateDialogIndirectParam() function.

Correct.

> When I set a break point and disassembled the code, the following is
> what
> I
> got:
>
> hWnd = ::CreateDialogIndirect(hInst, lpDialogTemplate,
> pParentWnd->GetSafeHwnd(), AfxDlgProc);
> 7C2364D0 mov ecx,dword ptr [pParentWnd]
> 7C2364D3 call CWnd::GetSafeHwnd (7C28E080h)
> 7C2364D8 mov dword ptr [ebp-94h],eax
> 7C2364DE push 0
> 7C2364E0 push offset AfxDlgProc (7C235B30h)
> 7C2364E5 mov edx,dword ptr [ebp-94h]
> 7C2364EB push edx
> 7C2364EC mov eax,dword ptr [lpDialogTemplate]
> 7C2364EF push eax
> 7C2364F0 mov ecx,dword ptr [hInst]
> 7C2364F3 push ecx
> 7C2364F4 call dword ptr [__imp__CreateDialogIndirectParamA@20
> (7C141A98h)]
> 7C2364FA mov dword ptr [hWnd],eax
>
> Notice the call to CreateDialofIndirectParam - my radio button click
> function is fired from this call.

As I said, an assertion is not proof. There may be a bug there. But
unless
you can say do X and Y results, and until that experience is replicated
by
others, what we have here is just a little annecdote.

I just checked an application of mine (~50K lines of Win32 C code) in
which
there is a single CreateDialogIndirect() call. I ran it on this XP/SP2
box.
I see no spurrious button clicks.

Look, I'm not saying there are no bugs in the platform. The knowledge
base
lists quite a few. But in the ten years that I have been reading this
group
and its predecessor on CIS, the overwhelming majority of new reports turn
out to be in the application code.

Regards,
Will


Jan 18 '06 #11

P: n/a
"John Gabriel" <Jo*********@discussions.microsoft.com> wrote in message
news:53**********************************@microsof t.com...
Jeff,

Looks like it might very well apply. All this happens in the
CreateDialogIndirectParam() routine. So if there is a WM_SETFOCUS being
sent,
I don't do it anywhere in my code.
Dialogs are obsessed with setting and restoring and eschewing the focus, so
it isn't suprising that you don't do it yourself.
It still seems illogical (to me) that the
BN_CLICKED notification is fired when a WM_SETFOCUS message is received
(unless that WM_SETFOCUS is caused by an 'actual' mouse click). As this
happens in the creation routine, no mouse button has been clicked and so
no
BN_CLICKED notification should be sent.

Despite that logical extrapolation, the mouse is only one way to cause a
button to generate a BN_CLICKED, and in any case, radio buttons -- however
illogical the reason, do it in response to WM_SETFOCUS: "For radio buttons
and automatic radio buttons, the parent window is sent a BN_CLICKED
notification message".
I tried changing the radio control properties so that no tab stop
generates
a WM_SETFOCUS but the mouse click notificatioin is still generated.


My guess is that the dialog focus logic operates as documented for its
processing of WM_SETFOCUS: "Sets the input focus to the control identified
by a previously saved control window handle. If no such handle exists, the
procedure sets the input focus to the first control in the dialog box
template that is visible, not disabled, and has the WS_TABSTOP style. If no
such control exists, the procedure sets the input focus to the first control
in the template".

--
Jeff Partch [VC++ MVP]
Jan 18 '06 #12

P: n/a
> Despite that logical extrapolation, the mouse is only one way to cause a
button to generate a BN_CLICKED, and in any case, radio buttons -- however
illogical the reason, do it in response to WM_SETFOCUS: "For radio buttons
and automatic radio buttons, the parent window is sent a BN_CLICKED
notification message".
I can understand the scheme you described working fine for many controls but
find it strange it also applies to radio buttons.
My guess is that the dialog focus logic operates as documented for its
processing of WM_SETFOCUS: "Sets the input focus to the control identified
by a previously saved control window handle. If no such handle exists, the
procedure sets the input focus to the first control in the dialog box
template that is visible, not disabled, and has the WS_TABSTOP style. If no
such control exists, the procedure sets the input focus to the first control
in the template".


Just because the logic operates as documented does not mean it is correct.
It is wrong to have WM_SETFOCUS generate a BN_CLICKED because BN_CLICKED
should only be generated by an actual button click on the control whether or
not it has focus. Evidently (and I hate to say this) Microsoft developers
were not thinking properly when they implemented this. So what's new.....

Well, thanks for your contribution Jeff, but fortunately I was able to yet
once again produce a workaround and I have much experience in doing this with
buggy Microsoft products. How ridiculous it is for a developer to spend time
playing detective with Microsoft's window messaging scheme and the illogical
way in which they do things. It is so annoying and if I had a choice, I
would steer clear of all that is Microsoft.
Jan 18 '06 #13

P: n/a
"John Gabriel" <Jo*********@discussions.microsoft.com> wrote in message
news:6F**********************************@microsof t.com...
Just because the logic operates as documented does not mean it is correct.


I see. So behavior at odds with the documentation would be correct, then?

Regards,
Will

Jan 18 '06 #14

P: n/a
No, unfortunately you do not see. You are not even close. Tell me Will, do
you think it is correct that a click routine be fired as a result of any
event other than an actual mouse click? Don't give me garbage about
circumstances under which it might be justifiable. It's not justified under
any circumstances. Now who is the only software producer who can claim that
as long as the behavior matches the documentation, then it is correct and get
away with murder?

If you are able to answer these two questions correctly, then I will concede
that you did in fact 'see'.

"William DePalo [MVP VC++]" wrote:
"John Gabriel" <Jo*********@discussions.microsoft.com> wrote in message
news:6F**********************************@microsof t.com...
Just because the logic operates as documented does not mean it is correct.


I see. So behavior at odds with the documentation would be correct, then?

Regards,
Will


Jan 19 '06 #15

P: n/a
"John Gabriel" <Jo*********@discussions.microsoft.com> wrote in message
news:BD**********************************@microsof t.com...
Tell me Will, do
you think it is correct that a click routine be fired as a result of any
event other than an actual mouse click? Don't give me garbage about
circumstances under which it might be justifiable.


LOL. First you ask and then you tell me you don't want to know.

My goal here is to keep the disinformation (and rancor, btw) to a minimum.

An innocent bystander reading this thread might be dissuaded from using
CreateDialogIndirect() because of your bogus "bug report". There is a huge
difference between a bug and something which does not work the way you think
it should.

In fact, what is happenning is that CreateDialogIndirect() causes at least
four messages to be sent to the dialog window - WM_NCCREATE, WM_NCCALCSIZE,
WM_CREATE and WM_INITDIALOG.

One of the handlers for one of those messages - the default provided by
Windows, your application code, or a library such as MFC is the cause the
message that troubles you. As the default handler for WM_INITDIALOG sets the
focus, Jeff's pointer may well be right on the money.

Just by the way, a novice Windows programmer would put a breakpoint at the
window procedure and have a resolution in 10 minutes or so. For an an expert
it would take about 90 seconds.

Regards,
Will
Jan 19 '06 #16

P: n/a
Actually I asked you nothing. You began to argue with me that my assertion
was incorrect. In fact, you are incorrect. I am not interested in your
opinion, only facts. You have not been able to say anything useful and have
an argumentative tone.

My bug report is anything but bogus. It is very valid and correct. Look,
readers will not be dissuaded by anything they read here. Readers are far
smarter than you give them credit. I do not consider any MVP to possess
knowledge that is terribly useful. I was hoping that someone who had run into
this bug would have been able to provide a quick solution. I found two
workarounds.

You sound like a novice programmer to me. You do not sound very
knowledgeable and frankly I would advise you to let others post who know the
answers. Stay with questions that you are absolutely certain you can answer
correctly.

Good luck to you!
LOL. First you ask and then you tell me you don't want to know.

My goal here is to keep the disinformation (and rancor, btw) to a minimum.

An innocent bystander reading this thread might be dissuaded from using
CreateDialogIndirect() because of your bogus "bug report". There is a huge
difference between a bug and something which does not work the way you think
it should.

In fact, what is happenning is that CreateDialogIndirect() causes at least
four messages to be sent to the dialog window - WM_NCCREATE, WM_NCCALCSIZE,
WM_CREATE and WM_INITDIALOG.

One of the handlers for one of those messages - the default provided by
Windows, your application code, or a library such as MFC is the cause the
message that troubles you. As the default handler for WM_INITDIALOG sets the
focus, Jeff's pointer may well be right on the money.

Just by the way, a novice Windows programmer would put a breakpoint at the
window procedure and have a resolution in 10 minutes or so. For an an expert
it would take about 90 seconds.

Regards,
Will

Jan 21 '06 #17

P: n/a
"John Gabriel" <Jo*********@discussions.microsoft.com> wrote in message
news:F2**********************************@microsof t.com...
Actually I asked you nothing.
You posted here a report of a "bug".
You began to argue with me that my assertion
was incorrect.
It is. There is no bug in CraeteDialogIndirect().
You have not been able to say anything useful and have
an argumentative tone.
You mispelled authoritative.
I was hoping that someone who had run into this bug would
have been able to provide a quick solution. I found two
workarounds.
No bug. In fact, I think you completely missed the fact that opening a
dialog engenders quite a few messages whose handlers can a do a lot of
things. That's a novice move.
You sound like a novice programmer to me.
LOL.
Stay with questions that you are absolutely certain
you can answer correctly.
I do,
Good luck to you!


Thanks.

Regards,
Will
Jan 21 '06 #18

P: n/a
> It is. There is no bug in CraeteDialogIndirect().

Wrong fool. You mispelled CreateDialogIndirect(). And yes, there is a bug -
it fires a radio button click routine without an actual click being
generated. I don't care what messages are generated or when, this is
incorrect whichever way you look at it.
You have not been able to say anything useful and have
an argumentative tone. You mispelled authoritative.


Actually I mispelled idiot.
No bug. In fact, I think you completely missed the fact that opening a
dialog engenders quite a few messages whose handlers can a do a lot of
things. That's a novice move.


Once again fool, it is a bug and the only novice here is you.
Stay with questions that you are absolutely certain
you can answer correctly.

I do,


Evidently you know even less than I thought and you will need more than luck!
Jan 22 '06 #19

P: n/a
"John Gabriel" <Jo*********@discussions.microsoft.com> wrote in message
news:E4**********************************@microsof t.com...
You mispelled CreateDialogIndirect().
Thanks for the correction.
And yes, there is a bug -
There is not. If you think so, file it. We get more than a few bug reports
here. And if it has any merit, otehrs will second it.
it fires a radio button click routine without an
actual click being generated. I don't care what
messages are generated or when, this is
incorrect whichever way you look at it.
I see, you don't care about the facts, just your unsupported assertion. If
your assetion were true, the function would behave as you describe in all
cases. This is where we began.
You have not been able to say anything useful and have
an argumentative tone.


I'm argumentative? Really?

Here is a quote from me:

"I'm not saying there isn't one (I don't have enough information to make
that
assertion) but I'm skeptical. If you can whittle the problem down to a small
example and post it here, someone may have better advice for you."

Here are a couple of your "best" ones:

"I have no interest in debugging Microsoft products."

" I am an expert assembly language programmer."

"Just because the logic operates as documented does not mean it is correct."

"Now who is the only software producer who can claim that
as long as the behavior matches the documentation, then it is correct and
get
away with murder?"

"Wrong fool"

Our agenda's our clear.

Mine is to offer advice, correct misperceptions and to provide counterpoint
to misinformation.

I'll take the high road and not categorize yours (it's pretty transparent)
except to point out that this exchange has been a lot of fun for me.

Regards.
Will

Jan 22 '06 #20

P: n/a
> Thanks for the correction.

You are not welcome.
There is not. If you think so, file it. We get more than a few bug reports
here. And if it has any merit, otehrs will second it.
As I said, I do not care to debug Microsoft products. If the idiots at
Microsoft think it is okay to fire any click event without an actual click
having taken place, it is their problem, not mine.
"I have no interest in debugging Microsoft products."
" I am an expert assembly language programmer."
"Just because the logic operates as documented does not mean it is correct."
"Now who is the only software producer who can claim that
as long as the behavior matches the documentation, then it is correct and
get away with murder?"
Yes, these are true and I stand by them. Thanks for restating them so that
anyone who reads the same knows what I wrote!
Our agenda's our clear.
You actually have an agenda? Agenda is a bad choice of words. I 'll let you
break your stupid head over it.
Mine is to offer advice, correct misperceptions and to provide counterpoint
to misinformation.
:-( You have done nothing of the sort except to be argumentative and
provocative to the point where I call you a fool. Indeed you are a fool and a
very annoying fellow to wit. To offer advice, you need to have knowledge (you
don't). To correct misperceptions, you need to know what is right and wrong
(you don't). To provide 'counterpoint' to misinformation? Only you have a
fuzzy idea what you mean here.
I'll take the high road and not categorize yours (it's pretty transparent)
except to point out that this exchange has been a lot of fun for me.


Well, I am glad it has been fun for you. It has not been fun for me. Dealing
with fools is something I do not enjoy. You have certainly shown yourself to
be a leader amongst fools.

Jan 23 '06 #21

P: n/a
"John Gabriel" <Jo*********@discussions.microsoft.com> wrote in message
news:06**********************************@microsof t.com...
You have certainly shown yourself to
be a leader amongst fools.


LOL.

Regards,
Will
Jan 23 '06 #22

P: n/a
To the readers: Notice how a Microsoft Valued Professional (MVP) reacts:

LOL.

Either the guy does not understand English or he is a retard. His best
response is LOL. I wonder if Microsoft trains its cronies to respond with
laughter when they do not have any answers? Perhaps this is a tactic to
relieve stress? Who knows....

Now let's see? Jeff Partch did the best he could and stated the truth: click
routines are fired without any actual clicks taking place. He confirmed what
I already knew. However, De Paolo not statisfied with Partch's response and
basking in his ignorance decides to take a hawkish approach.

His first annoying response:
"I see. So behavior at odds with the documentation would be correct, then?"

This microsoft valued 'professional' would rather argue with me and have fun.

Way to go Microsoft! Way to go!!!

"William DePalo [MVP VC++]" wrote:
"John Gabriel" <Jo*********@discussions.microsoft.com> wrote in message
news:06**********************************@microsof t.com...
You have certainly shown yourself to
be a leader amongst fools.


LOL.

Regards,
Will

Jan 30 '06 #23

P: n/a
"John Gabriel" <Jo*********@discussions.microsoft.com> wrote in message
news:EF**********************************@microsof t.com...
To the readers: Notice how a Microsoft Valued Professional (MVP) reacts:


Now I'm ROFLMAO.

Regards.
Will
Jan 30 '06 #24

P: n/a
??? Whatever do you mean? What does ROFLMAO stand for? Have we resorted to
obscene language now? Hmmm....

"William DePalo [MVP VC++]" wrote:
"John Gabriel" <Jo*********@discussions.microsoft.com> wrote in message
news:EF**********************************@microsof t.com...
To the readers: Notice how a Microsoft Valued Professional (MVP) reacts:


Now I'm ROFLMAO.

Regards.
Will

Jan 31 '06 #25

This discussion thread is closed

Replies have been disabled for this discussion.