Messages

I'll look into this later today or tomorrow.
This must have been a result from a recent sfml change.

I'm glad you find it useful.

There is no buglist as there are no known bugs. I usually fix bugs very fast, so if you do find a bug then just let me know and I'll try to fix it as soon as I find time for it.

Thanks, it has been fixed (old version might still be cached though).

The problem has been fixed in the latest development version.

This is indeed a problem. I guess it fails to load the images, I'll look into it.

I noticed that the black theme is still working, so in the properties change ConfigFile to the Black.conf file instead of the White.conf file for now.

I have never seen that error before so I can only guess.

But I did notice this in your error:

may conflict with libsfml-system.so.1.7

So I think you may have an older sfml version still installed somewhere on you system that is causing problems.

It might lag behind a little bit, but it will mostly up-to-date.

The only widget that isn't ported (and won't be ported soon) is TextBox. But that is because it even isn't usefull in the c++ version.

Other than that, the only thing that I am aware of that hasn't been ported yet is the copy & pasting.
The code is actually already placed in EditBox.cs, but it is still in comments because isKeyPressed seems to crash. (I don't have time to investigate this, but maybe you can check if it works for you when uncommenting this block of code).

In short, it won't be more than one or two changes behind and it is kindof up-to-date right now. (and because no new changes are planned soon, it will stay like this for a while)

This is an old topic. What is said here isn't relevant anymore because TGUI now uses C++11.

On my linux system, I compile SFML + TGUI without C++11 enabled.

That isn't supposed to work, unless the compiler has -std=c++11 by default.
But keep in mind that I set this option in my cmake script myself, so unless you change the flags, you will be compiling tgui with c++11.

This 'bug' is a little bit tricky.

You can create widgets at a later moment, it should work if you don't so this with the widgets inside the panel but directly into the gui.

The thing is, every widget uses the font of its parent by default and will thus only receive its font when added to a parent. You are adding widgets to the panel, before the panel has a font, so the widgets will have no fonts. Once the panel gets added to the gui, it will get its font but it won't pass this to all it widgets (doing that would make it pretty hard to use multiple fonts within one panel).

So one solution is to give the panel the font directly after creating it.

Code Select Expand

var panel = new Panel ();
panel.GlobalFont = gui.GlobalFont;

But keep in mind that when you use a different font in the above code, the font of the panel will be overwritten again when it is added to the gui (but the widgets that were already added are still using the font that you wanted).


So this is al very complex, so maybe you should ask yourself if it is really necessary to go this way.
It all started with you saying that you want to construct the panel BEFORE adding it to the gui.
I think that what you are trying to do can be easily achieved by doing the following:

Code Select Expand

var panel = gui.Add (new Panel ());
panel.Visible = false;
// ...
panel.Visible = true; // This is the moment that you would add the panel to the gui

Done. Panels are now visible by default (light grey background).

It seems like more things went wrong while porting the code to c# than I expected.

Fixed.

It seems like this has already been fixed in the c++ version.

It must have been a change that I missed when changing the .Net port.
I'll try to fix this as soon as possible.

Edit: Fixed.

I'll set it to (100, 100).

Default size for Panel and ChildWindow is needed anyway if I want to add them to the form builder in the future.

Edit:
Do you also want a default color (e.g. white)? Because right now it is transparent by default for when you just want to use it as a group of widgets, but that means it is still invisible when you create it.

This might be caused when the images can't be loaded.
Make sure that the file given by the value of NormalImage_L ("Button/White/Normal.png" I guess) exists.
The path is relative from the config file (so the Button folder has to be in the same folder as White.conf).

I guess the errors could be more clear. I'll change that later today.

Thanks for investigating on the bug.

I made the m_Focused variable default to false, because in all my tests a focused event would be send when creating the window.

Anyway, I now changed the default value to true, so it should now work with the latest version.

Strange, it works fine for me. The animation of course stops at the last frame because it isn't looping, but at least I have an animation.

I'll look into this later today, because I don't really know what version I tested it with, so there is always the chance that I'm not using the same version as you.

There is one thing to understand about the widget files: the 'Window: ""' does absolutely nothing .

It is preserved from previous versions where the Gui class was still called Window, but that is not the real reason for this Window line.
The idea was that you would be able to place multiple windows/frames into a single text file and then you would tell loadWidgetsFromFile which one to load.  However this has not yet been supported and the line is indeed redundant.

I haven't decided yet what to do with the Window part. But it isn't really a big issue, you can still do everything including loading child windows, as long as you have the whole file in a Window block.

"widgets/EditBox/White" should be "widgets/White.conf".

The code gets into an endless loop trying to read from a folder instead of a text file.

I have been able to reproduce it with the version that you use and this is indeed a problem in that version.

But you downloaded the precompiled binaries for windows (which might have not been clear from the download page, my fault).
If you compile it yourself (like you have to do on linux) then you should just download the latest development version. This issue seems to be fixed there already.

This looks like it has more to do with your graphics driver than with tgui. I wouldn't have any idea what else could cause this.

But one question remained unanswered: can you reproduce it with just using sf::Text?

Edit: Also, are you compiling with the -std=c++0x flag?

On which operating system?

Do you have the same problem with just using sf::Text?

Could you provide a small code example which fails for you?

I'll look into the problem.

You should try with the latest development version instead of with the beta.

The function is for binding functions in your own classes, so it expects a normal pointer and not a smart pointer (the popupWindow).

You'll need to write it like this (get returns the internal pointer).

Code Select Expand

icon->bindCallback(&tgui::Widget::show, popupWindow.get(), tgui::Button::LeftMouseClicked);

VS2010 is still supported (and will stay supported), but you must compile the library yourself (just like you would have to do for e.g. VS2013).

I cannot provide precompiled libraries for compilers that I don't have on my pc.

My skypename is texusius.