wxWidgets Discussion Forum

OK, how about other embedded systems? If it runs Linux with GTK or X11, there is a good chance, wxWidgets will build on it. There is also wxDFB (FB for framebuffer) which displays a Gui by writing directly into the framebuffer of the graphics card (without running GTK, X11 or similar), but i don't ...

If you're talking about a Raspi with GUI (GTK or X11), it definitely works.

Unfortunately all these sites have their own user management, the accounts are not shared among them.

In general it's to good starting point to check the list of open bugs and try to fix one. http://trac.wxwidgets.org/ You can also check recent Google Summer of Code projects and project ideas: https://www.wxwidgets.org/gsoc/projects/ Some of them might already be implemented by now. Before you start...

El_isra wrote: ↑

Tue Apr 20, 2021 12:33 pm

sizers only work for element layout?

Yes.

El_isra wrote: ↑

Tue Apr 20, 2021 12:33 pm

some users reported some buttons and text become bigger.

No, sizers don't do that.

I think this is a good introduction to understand the basic concept behind sizers:
http://neume.sourceforge.net/sizerdemo/

Use wxPixelData to write directly into the bitmap, without the vectors: https://docs.wxwidgets.org/trunk/classwx_pixel_data.html As you're just writing into memory, it's safe from multiple threads. But you must destroy the wxPixelData instance before you use the bitmap for any other operation, like ...

Pass as "style" to the wxWindow ctor. And must not have the "dc.Clear();" in the paint event handler.

mael15 wrote: ↑

Sun Apr 18, 2021 7:57 am

I am wondering why a "simple and clean" EVT_KEY_UP is not triggered while EVT_CHAR is. Any idea?

Not really. Got any sample code i can play around with? I'm lazy on a sunday

Add the wxTRANSPARENT_WINDOW style flag.
Call SetBackgroundStyle(wxBG_STYLE_PAINT); in the ctor, so that its background does not get cleared.

Memory leak: You need to call "delete gc;" at the end of the paint event handler.

int x0=100,y0=100,x1=0,y1=0,x2=0,y2=0,D1=40,D2=60; I suspect these hard-coded coordinates to be responsible. Inside a paint event handler for a specific window, the coordinates are relative to the window position, i.e. they always start at (0,0) in the upper left corner. I guess you're drawing outs...

Is this all about avoiding to delete multiple items because of the key-repeat of the delete key?

Under Windows you can get this information from wxKeyEvent::GetRawKeyFlags(). If bit 30 is set, the event is the result of an auto-repeat.

How exactly did you try to build the samples? They all should build fine from the command line using the provided make files.

If you try to build them in CodeLite, you'll probably have to add the missing libraries to the linker options yourself.

I usually don't work under Linux, but i have a faint memory that window creation under GTK is somehow delayed compared to window creation under Windows. I assume the Layout is calculated before the wxStaticText is aware of its new font size. I thought there was an open ticket about this on http://tr...