wxWidgets Discussion Forum

You probably need wxNativeWindow.

Probably that's how doxygen works.

greenzyzyzy wrote: ↑

Mon Jul 06, 2020 12:32 pm

wxcombobox.not have Append( )

Yes it has:
https://docs.wxwidgets.org/trunk/classw ... 9e925f8bc4

Did you try Append(), Insert() for the first two? They're right there in the inheritance chain.
InsertItem() for the latter, just read the docs or see the samples.

IIRC whatever you put in there will not get focused. So if you intend to interact with them using only the mouse, all should be fine, but if you need kb input then it might not work as you expected.

Not really, because the latter is used from wxPopupWindowHandler, which is only used by non-MSW implementations.
But it's probably not too difficult to do something similar in your derived class, connecting to the relevant mouse event [and ensure capturing and releasing the mouse when needed].

Remove `bSizer1`, `sbSizer1` and `sbSizer2` (not their contents) from your layout, they are useless anyway, in case you missed a relevant flag or proportion for them.

Well, FWIW the popup window code is a mess. The "common" code actually contains the OSX and GTK implementations (..not exactly "common"), while the MSW implementation is separate. But you're probably right as it does look like a bug (assuming the reason for not getting those calls is because you're ...

wxPopupWindow has no OnDismiss() member. You're probably aiming for wxPopupTransientWindow::OnDismiss(). But mind that it will be called only when Dismiss() was not called. At least for wxPopupTransientWindow::ProcessLeftDown(), it sounds like you are doing something wrong. Can you show a piece of c...

The submitted form was invalid. Try submitting again. when trying to reply to a topic (or start a new one). I tried a different browser, same result. This is now happening to me since yesterday when attempting to reply to a topic. The sid value in the address url keeps changing after every click on...

Switching to utf-8 might indeed solve this. I remember it being available on Windows too (someone contributed some fixes for this some time ago, although I couldn't find that information anymore), and apparently wxString does iterate correctly over variable-width code points in utf-8.

The explanation with surrogate pairs is the right one IMO. wxTextCtrl will handle them correctly in all scenarios, while in this particular case, wxRTC will not, and a fix for that is unlikely. The problem is not necessarily with wxRTC per se, but significantly deeper -- it's because wxString does n...

catalin here is probably catalinr who actually wrote MSWMoveWindowToAnyPosition(). :) Yup, guilty as charged... But my use case back then only had a few windows positioned beyond SHRT_MAX, and didn't notice this problem. So I guess he will take care of reporting or even fixing the issue. Actually I...

Can you try with changing wxWindowMSW::MSWIsPositionDirectlySupported() to always return true, and see if your workaround still runs as in the older version?

The code with (2) runs as expected, i.e., the frame shows immediately and can be normally resized. I'm still curious about what "as expected" should actually mean. From what I tried, by disabling the code in that commit (changed MSWIsPositionDirectlySupported() to always return true), the frame did...