Main Menu
Menu

Show posts

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 Menu

Messages - wizzard

#1
Good luck with exams! I hope my way keeps working with all types of widgets.
#2
I want to know if any widgets in a Gui have focus. If not, I allow my game engine to handle events. I currently do this by looping through all the widgets in the Gui. I was disappointed to see how Gui::hasFocus worked.
#3
Thanks for this change! I will notify you if there is some weird behavior on Windows.
(but I'm pretty sure the window is focused at first on all Windows platforms)
#4
I guess the first post is a bit confusing...

When the SFML render window does not have focus, the TGUI edit box has a flashing caret.
I just want it stop flashing when the SFML render window is not focused.
The point I was trying to make up above is that the TGUI edit box should still be focused regardless.
However, the little flashing caret should stop flashing when you can't type into the box.
If the SFML render window does have focus again, I would be able to type into the box.
So, the flashing caret would depend on whether or not the SFML render window has focus.
#5
The flashing of the selection point happens via mainWindowGui.draw() though

Edit: By the way, I tried it just in case it oddly worked
#6
To implement this, TGUI would need to keep track of whether the SFML window has focus using its events
When the SFML window does not have focus, the selection point would not be drawn ever

Edit:
It might also be worth exposing the function with tgui::Gui::hasFocus
#7
I keep getting fooled into thinking that I can type in my client window when it isn't selected.
This is because the caret is flashing even though the window does not have focus.
The EditBox should still use its focused images, but I just wish that the selection point would stop flashing.
#8
I have not ported all of TGUI and so I do not know if those are the only two functions that feature this issue

Those are the only ones I've run into so far though

Edit: ... and yes, making them no longer internal fixes the issue
#9
I'm sorry. I actually have no issue with the get function
That is documented just fine. That was my error and I will remove it from the original post

Edit: To reiterate my problem with the two functions in the original post,
the thing they have in common is that only one of their overloads is documented
#10
Making certain functions no longer internal fixes this problem too

My issue is that the documentation isn't matching results when using templates
#11
Quote from: wizzard on 19 September 2013, 14:17:07
I think it'd be a good idea to instead append "Internal" to all the internal functions.
That was meant as an alternative to the way SFML does it.
I do not think at this point there is any benefit to doing it the same way as SFML.
No namespace is needed - just renaming the internal versions of the functions and
renaming all the places where the internal versions are called.
#12
I do a lot of template work with TGUI since I expose it to the Squirrel scripting language using them.

When I look at the documentation, I see functions like the following
tgui::Container::focusWidget
tgui::Container::remove

These functions have undocumented (internal) overloads that are exposed.
So, when I go to shove them into my templates they do not work because of template ambiguity.
With these functions, I can just define the template of the function I want bound.
Anyways, the problem I have is that it took awhile for me to realize they had internal overloads.
In addition, I'm pretty sure IDE auto-completion will see the internal overloads and recommend them.

SFML handles internal functions by putting them in a "priv" namespace.
I think it'd be a good idea to instead append "Internal" to all the internal functions.
(e.g. tgui::Container::focusWidgetInternal)
#13
Rename to getLineAmount?
Reasoning:
- getWidgets returns a container of widgets.
- getLines would return a container of lines.
#14
Thanks for that! This makes it much faster for me to get an update from TGUI.
#15
Feature requests / Automatic doxygen usage in CMake
18 September 2013, 17:10:09
SFML has it so CMake automatically tells the makefile to compile the documentation for it.

It'd be a tad cooler if TGUI did that too. I can just do mingw32-make install and it puts all the documentation in a folder.