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

[Guest]

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??

 

[William DePalo [MVP VC++]]

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

 

[Guest]

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:

 

[Guest]

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

 

[Guest]

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.

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

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

 

[William DePalo [MVP VC++]]

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

 

[William DePalo [MVP VC++]]

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

 

[Guest]

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

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

 

[William DePalo [MVP VC++]]

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

 

[Jeff Partch [MVP]]

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]

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

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

 

[Guest]

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

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]

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

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 Partch [MVP]]

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".

 

[Guest]

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.

 

[William DePalo [MVP VC++]]

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

 

[Guest]

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++]]

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

 

[Guest]

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!

 

[William DePalo [MVP VC++]]

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

 

[Guest]

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 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.

I do,

Evidently you know even less than I thought and you will need more than luck!

 

[William DePalo [MVP VC++]]

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