John Ehresman wrote:
Robert Roessler wrote:
Yup - just restoring the original [subtracted] code for the else
clause works fine... I copied the reported diff lines back in, so that
it supports both the old logic and the new breaking logic - with the
new being given a shot first, and the original code only being run if
the new uri recognition stuff fails.
Are you referring to the else if (selection_data->length > 0) clause at
the end of ScintillaGTK::ReceivedDrop? Maybe you better post diffs,
because I can't quite understand exactly what you're referring to.
The call to NotifyURIDropped on any type of selection data seems a bit
dubious, though I haven't look at this in detail. Maybe the uri list
comes in as another selection type on win32.
All that I am suggesting is restoring the exact code that was present
in the [to you] non-working old code - which worked properly from my
perspective as a GTK Scintilla client *on Windows XP* - BUT NOT by
pulling out the new (first if clause) code, just restoring the final
else clause that you refer to above.
In the worst case, if you as someone who knows way more about GTK feel
strongly that that code is somehow "wrong" (twisted, evil, etc) in the
larger GTK scheme of things, then perhaps this could have the good old
PLAT_GTK_WIN32 ifdef control applied so that it only is present in
GTK-on-Windows builds - because it used to "just work" in that
environment, and is now badly broken. ;)
As was already in the reply to Neil, the file with the old code
restored is at
http::/www.rftp.com/ScintillaGTK.cxx
Robert Roessler
[EMAIL PROTECTED]
http://www.rftp.com
_______________________________________________
Scintilla-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scintilla-interest
