[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] A GUI test for pasting

From: Vadim Zeitlin
Subject: Re: [lmi] A GUI test for pasting
Date: Sat, 2 Feb 2008 21:54:26 +0100

On Sat, 02 Feb 2008 20:34:43 +0000 Greg Chicares <address@hidden> wrote:

GC> Vadim, would you please look at this change I just made:
GC>   http://cvs.sv.gnu.org/viewvc/lmi/lmi/main_wx.cpp?r1=1.91&r2=1.92
GC> and tell me what I'm doing wrong? I'm trying to follow a
GC> casual sketch you laid out long ago in an off-list email
GC> from 2006-08-12T01:25Z (which is why I ask you by name--not
GC> to exclude Vaclav if he sees this first)

 To restore context, here is the relevant extract:

VZ> GC> 2. Is there some easy way to test this under program control? I'm
VZ> GC> thinking that we want to take a string like
VZ> GC>   "Excel\0[Book1]Sheet1\0R1C2:R7C2\0\0"
VZ> GC>   [from your inline example...but with some data added]
VZ> GC> and do something like
VZ> GC>   wxCommandEvent event(wxSOME_PASTE_COMMAND, OurExcelString);
VZ> GC>   wxPostEvent(some_text_control, event);
VZ> GC> but it would take me a while to figure that out, while you could
VZ> GC> probably write it in your sleep.
VZ>  We're in an ideal situation then as I'm half asleep :-) I didn't test it
VZ> but these lines should do the trick:
VZ>     // first put the data in the correct format on clipboard
VZ>     wxString s("Excel\0[Book1]Sheet1\0R1C2:R7C2\0\0");
VZ>     wxDataFormat dfLink("Link");
VZ>     wxCustomDataObject *do = new wxCustomDataObject(dfLink);
VZ>     do->SetData(s.length(), s.c_str());
VZ>     wxTheClipboard->AddData(dobj);
VZ>     // second generate an event to pretend that text was pasted
VZ>     wxClipboardTextEvent evt(wxEVT_COMMAND_TEXT_PASTE, GetId());
VZ>     evt.SetEventObject(some_text_control);
VZ>     wxPostEvent(some_text_control, evt);

GC> but I can't get the paste handler to change the text from its initial
GC> contents.

 Unfortunately writing this while half asleep was a bad idea as this was
totally wrong and had no chance of working because our handler reacts to
the native WM_PASTE event and so can't be triggered by a wx event. Even
more unfortunately, this is just a particular instance of a general
problem (you can't make (native) controls react to wx events) and we know
that there is no good solution to it. In this particular case you could
write the test working only under wxMSW using MSW-specific code (e.g.
::SendMessage(GetHwndOf(some_text_control), WM_PASTE, 0, 0)) but this is
not really acceptable because not only it leaves other platforms untested
but it's also difficult to generalize to other cases.
 A more general solution would be to have a virtual wxEvent method which
would allow synthesizing the native event which corresponds to this wxEvent
(i.e. providing a way to reverse the unidirectional mapping between the
native events and wxEvent which is the only thing implemented in wx
currently). This would definitely be useful in a lot of situations, and not
only for testing, even though it's clearly very useful for testing and the
last time discussion about it arose on wx-dev it was also in a testing
framework context[1]. But it would require some time to do it and, worse,
it can't be done in 2.8 branch as it wouldn't be ABI-preserving (although
maybe we could find a way around it but I'd need to think more about it).

 Anyhow, to summarize, right now there is no way to test the paste handler
programmatically without using platform-specific code. I'd love to
implement a (general) way to do it to wx itself and I think it would be
relatively simple to do it but I don't know if it is going to be useful for
you if you need it right now.

 And sorry once again for writing incorrect code in the original email,

[1] See http://thread.gmane.org/gmane.comp.lib.wxwidgets.devel/97074
    BTW, while I didn't look at it yet, I think that it might make sense to
    use this testing framework rather than reimplementing it inside LMI.
    It is built around the same idea (basically wxPostEvent() + wxYield())
    but is probably more extensive and, anyhow, why duplicate the work.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]