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??
24  4454 
"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
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
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
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
"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
"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
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
"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
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
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
"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]
> 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.
"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
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
"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
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
"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
> 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!
"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
> 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.
"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
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
"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
??? 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
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: sman |
last post by:
Hi, I recently read this article on About.com on how to create
required fields for a form:
http://javascript.about.com/library/scripts/blformvalidate.htm
Everything works great except that there...
|
by: DettCom |
last post by:
Hello,
I would like to be able to display or hide fields based on whether a
specific Yes/No radio button is selected. This is in conjunction with
a posting a just made here in the same group...
|
by: HD |
last post by:
Hi.
I have an asp page with radio buttons and a combobox... when the user clicks
a radio button, I want the form to submit so I can execute the ASP code in
order to change the list shown in the...
|
by: MickG |
last post by:
I am trying to change the value of the variable "hard" according to
which radio button is pressed and I am having no joy. Could anyone
help me with this, the problematic section is marked with...
|
by: John Davis |
last post by:
I created a ASP.NET Web Form using VB.NET with a text box, 2 radio buttons.
When the user click the first radio button, the text will change to
uppercase. If the user clicks the other radio button,...
|
by: Mike Salter |
last post by:
I created a page that reads a DB for questions and possible answers
(usuallyYes/No). I create a panel for each group of questions, and add a
panel for each question to the Group panel. To the...
|
by: nathaniel.k.lee |
last post by:
Is it not possible, in IE, to dynamically click a radio button? I'm
grabbing some values from a database and using them to populate radio
buttons on a page. I have alternate code for Firefox...
|
by: Saul |
last post by:
I have a set of radio buttons that are created dynamically, after
rendered I try loop thru this set by getting the length of the set, but
I keep getting an error stating the element is undefined. I...
|
by: namanhvu |
last post by:
Hi everyone,
I'm trying to create a form where the radio button is automatically
selected when the input text field beside it is clicked. I know I need
to use "onClick" somewhere but I don't...
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
| |
