wxWidgets Discussion Forum

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

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

Oh, so quickly! If you're still curious and still have some time, maybe you can just comment the 2 ::ScrollWindow() calls in MSWMoveWindowToAnyPosition() and see if that changes anything.

If ::ScrollWindow() is the cause, using deferred sizing along with it would not change anything.

Anything is possible, but the long time appears to be spent inside ::ScrollWindow(), which would be needed even if deferred sizing was used.

Another test would be to add Some Freeze()/Thaw() in MSWMoveWindowToAnyPosition(), around ::ScrollWindow() calls.

The problem with positioning children outside Short range was visible only when scrolling to / over maximum Short values. Children located below those values would look just fine.