Stupid me:
I overlooked getTextsize and setTextsize functions.
Ingar
I overlooked getTextsize and setTextsize functions.
Ingar
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Show posts MenuQuote from: texus on 11 September 2020, 17:50:04
This is the default SFML behavior (which I am no longer using in 0.9-dev exactly because most people probably don't want it).
You have to call gui.setView when you receive the Resized event, using the a view with rect (0, 0, newWindowWidth, newWindowHeight).gui.setView(sf::View(sf::FloatRect(0.f, 0.f, static_cast<float>(event.size.width), static_cast<float>(event.size.height))));
Quote from: texus on 04 June 2019, 16:22:00
I don't see anything wrong with your steps.
Maybe storing the buffer in an std::string can be skipped if fromUtf8 supports a begin and end pointer (I'm not sure if it does), but it will work equally well when first stored in an std::string.
The type is Uint32 because it stores the string as UTF32. Two bytes wouldn't be enough to store ALL possible unicode characters.
If squares are displayed then it would mean that the chosen font (arial.ttf in this case) does not contain these japanese characters.
Quote from: ingar on 07 May 2019, 21:53:12
Hi all,
A general question:
Are there any ways of supporting Unicode in TGUI? I am hoping to be able to replace a Windows CE application with a TGUI app. But the Windows CE app is connecting to a server that returns UTF8 data.
And I cannot see how to TGUI can display those Japanese names...
Ingar
Quote from: texus on 05 May 2019, 09:51:09
You can't access the same SFML or TGUI objects from multiple threads at the same time, it is up to you to do the synchronization. One way would be to use mutexes around the TGUI objects you access, but that will likely decrease performance as you would have to lock practically everywhere in the main thread (locks around both event handling and drawing and anywhere else where you access TGUI widgets). So the best way is probably to only let the main thread access TGUI and get your data to the main thread somehow. How to do this is of course not related to TGUI.
I don't have much experience with syncing between threads myself, other than on a windows-only project that uses the Windows functions like PostMessage, SetEvent and WaitForSingleObject.
A pure c++ alternative to SetEvent/WaitForSingleObject would probably be to have a mutex around a shared variable. Every frame (or every X milliseconds) you lock the mutex, check the variable and unlock the mutex again. In the other thread, when data is read from the card, it locks the mutex, writes the data in the variable and unlock the mutex again.
Quote from: texus on 02 May 2019, 18:10:58
Is there anything that prevents you from just keeping the window and gui and just calling gui.removeAllWidgets() and adding the widgets for the next screen?
Multiple screens could be prepared upfront by creating a Group widget per screen (and adding the widgets to the group instead of to the gui). Then showing another screen is as simple as calling group1->setVisible(false); group2->setVisible(true);
Or maybe use a tgui::ChildWindow instead of an actual window?
Quote from: ingar on 02 May 2019, 14:53:31
Hi again,
Thanks. I will try to re-use the RenderWindow.
My application has a main window, and a button for starting a "Setup" window. So what is then the best procedure?
A: Creating a new RenderWindow and a new Gui, as I am doing now
B: Re-using the RenderWindow with a new Gui.
The change in my code will then be to let the "Back" (or "OK") button just set a "Finish" flag,
instead of, as now, closing the RenderWindow.
C: Other method?
IngarQuote from: texus on 30 April 2019, 15:57:19
tgui::Gui just keeps a pointer to the RenderWindow, it will not destroy the window when the Gui gets destroyed. You only have to make sure not to call functions on the Gui object after the window it uses has been destroyed.
Why do you need a second sf::RenderWindow? Can't you just continue to use the existing window? If you really need a second window then you also need a second Gui that renders to that window.