[ wxwindows-Patches-1447739 ] Fix wxFindReplaceDialog for multiple... wxFindReplaceDialogs

Sun Apr 1 05:06:00 PDT 2007

Patches item #1447739, was opened at 2006-03-11 06:47
Message generated for change (Comment added) made by vadz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=309863&aid=1447739&group_id=9863

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: MSW specific
Group: bug fix
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Ryan Norton (ryannpcs)
Assigned to: Vadim Zeitlin (vadz)
Summary: Fix wxFindReplaceDialog for multiple... wxFindReplaceDialogs

Initial Comment:
OK, here we go - this patch is ugly in some ways...

Basically, there are quite a few reasons why it is the 
way it is:

1) the owner of the findreplace dialog --HAS-- to be 
the real parent of our wxFindReplaceDialog, otherwise 
the initial positioning is screwed up (hackable at 
least here is a ::MoveWindow) and the window Z order is 
wrong (if the parent of the findreplace dialog shows a 
modal dialog the findreplace dialog is put under the 
parent window) [don't take my word for it, try out my 
hidden-window version DONOTAPPLYfrchild.cpp]

2) We can't use wxSetWindowProc on the parent because 
what happens if someone sets it later - we could get 
infinite recursion EASY

3) We absolutely should not use the userdata of the 
parent window because 
3A) Someone else might have used it before
or
3B) Someone else or wx might want to use it PERIOD

4) We could try to handle more in src/msw/window.cpp 
but the wierd hacks with the MSLU static variables 
would make this just nasty

Of course, feel free to modify it and if you have a 
better idea this will at least get you a head-start :).

----------------------------------------------------------------------

>Comment By: Vadim Zeitlin (vadz)
Date: 2007-04-01 14:06

Message:
Logged In: YES 
user_id=71618
Originator: NO

The idea of avoiding needlessly subclassing the window is definitely a
good one, thanks Ryan. However I didn't like that much introducing a
dependency of wxWindow on wxFindReplaceDialog, this doesn't seem right. So
I've implemented a generic mechanism for registering global (i.e. for all
windows) handlers for custom messages at wxWindow level and used it to call
wxFindReplaceDialog handler for FINDMSG message.

Seems to work fine for me, further testing definitely appreciated.

----------------------------------------------------------------------

Comment By: Ryan Norton (ryannpcs)
Date: 2006-12-09 12:25

Message:
Logged In: YES 
user_id=678955
Originator: YES

...and to clean up the Win32 HWND userdata practice as well. It was just
meant as a proposal though and a gesture for ideas, but if there is no
better solution then the current one works in the strictist sense.

----------------------------------------------------------------------

Comment By: Ryan Norton (ryannpcs)
Date: 2006-12-09 12:23

Message:
Logged In: YES 
user_id=678955
Originator: YES

The gist of the patch is that it allows you have to have multiple
wxFindReplaceDialogs at one time, which the current implementation still
doesn't appear to do...

----------------------------------------------------------------------

Comment By: Ryan Norton (ryannpcs)
Date: 2006-12-09 12:18

Message:
Logged In: YES 
user_id=678955
Originator: YES

http://lists.wxwidgets.org/cgi-bin/ezmlm-cgi?5:mss:71545:200603:bbfldjoieoeokohaoekn

was the original post. The next post in the thread describes the patch
more.

As I recall there was another thread from Robin with some kind of
followup.

----------------------------------------------------------------------

Comment By: SourceForge Robot (sf-robot)
Date: 2006-11-13 04:20

Message:
Logged In: YES 
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: Vadim Zeitlin (vadz)
Date: 2006-10-29 21:00

Message:
Logged In: YES 
user_id=71618

I don't know what to do with this any more. The patch
doesn't apply, of course, after all this time and I still
have no idea about how to reproduce the bug (I didn't find
any message from Ryan in the list archives although I did
search).

----------------------------------------------------------------------

Comment By: Ryan Norton (ryannpcs)
Date: 2006-03-12 18:48

Message:
Logged In: YES 
user_id=678955

The default message handler way is good.

I gave a cheap example on the list to test it and to be honest I think
that 
is probably all you'll need to be able to test this...

----------------------------------------------------------------------

Comment By: Vadim Zeitlin (vadz)
Date: 2006-03-12 15:26

Message:
Logged In: YES 
user_id=71618

I agree that it's a better idea to do it like this. I don't
like making window.cpp depend on wxFindReplaceDialog though
nor calling this function even when we don't use this dialog
at all (99.99% cases probably)... I think I'm going to make
it possible to register default message handlers and use
this to register wxFindReplaceDialogImpl::HandleFindReplace
when the dialog is created/shown. What do you think?

BTW, do you have any example code exercising the current
problems in this class (it's impossible to show 2 of them
simultaneously right now I believe?)? Because the dialogs
sample seems to work just fine even without any changes
which makes testing difficult.

Thanks!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=309863&aid=1447739&group_id=9863