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

#1776
push_back is a function from vector and has nothing to do with tgui.
So you might just want to look up some tutorials about the STL vectors to understand this better.
#1777
That is really strange.

I'm going to sleep now, but tomorrow I'll see if I can get a windows up and running to test this myself.

In the meantime you could try to link statically and see if it makes any difference.
#1778
Yes, TextBox is extremely slow and it is planned to be rewritten before v0.6 is finished.

Try using ChatBox instead for a console.
Then you could use an EditBox to type a new line.

ChatBox will be slow on linux with sfml 2.0, but there is no problem on windows or when using the github version of sfml.
#1779
QuoteNow i have to deal with "Why program takes 34-40% CPU when i click to open Group1, and it was using 4% when on main screen and loginScreen.
Does your code sleep anywhere?

You should use sf::sleep in your main loop to just sleep like 1 millisecond.

If you don't do this then your code could even take 100% of one processor. Why it would suddenly increase I don't know, but if you don't let the program rest for a moment then such things could happen.

If you already use sleep then it is indeed an issue (one that I can't explain).

QuoteI can upload entire project if you want to
Not needed. I won't spend my time looking at someone elses code unless I have a reason for it.
#1780
Could you show me the code where you are creating edit boxes in Group1Napomene?

Perhaps you should just upload the whole code, so that I can look for the mistake myself.

The problem probably isn't in the lines that I posted, it lies somewhere else.
A possible problem would be that you let the edit box numbers count from 1 somewhere while in this part of code it starts from 0.
#1781
Group1Napomene exists, because otherwise it should give that error somewhere else, but does it have those edit boxes inside? Because this error indicates that it can't find the requested edit box in Group1Napomene.
#1782
The edit in your previous post actually made it more clear to me what you are trying to achieve.

So this should be what you want:
tgui::Panel::Ptr Group1 = gui.get("Group1");
tgui::Panel::Ptr Group1Napomene = gui.get("Group1Napomene");

for (unsigned i = 0; i < 30; ++i)
{
    tgui::EditBox::Ptr Ime1 = Group1->get("Ime" + tgui::to_string(i));
    sf::String text = Ime1->getText();

    tgui::EditBox::Ptr Ime1napomene = Group1Napomene->get("Ime" + tgui::to_string(i));
    Ime1napomene->setText(text);
}
#1783
Did you add anything to Ime1napomene earlier (with the push_back function)? What is supposed to be in there?
#1784
Is that code inside a for loop?
I think this is what you are trying to do:
Ime1napomene[i]->setText(Group1Names[i]);
#1785
Is Ime1napomene supposed to be an edit box or just some text?
Right now it is an sf::String, which doesn't has the setText function.

If it is supposed to be a string like it is now, then the line should be
Ime1napomene = Group1Names;
#1786
I was talking about generating a project instead of a makefile.
But if you selected NMake makefiles and build it with VS2012 then it should be fine.

I was downloading VS2012 myself when I got a BSOD, so I am now completely reinstalling windows. So maybe in a few hours I can test things myself.

Edit:
Quotehm seems I'm uing the 2010 command prompt, cant find the 2012
That's what causing the problems. You can open the command prompt from inside VS.
Edit: Apparently not.
#1787
QuoteI'm using Visual studio 2012 express
QuoteI'm using this one in VC++ 2013
Which one is it? If it is not 2012 then I would recommend rebuilding sfml as well.

Technically VC++2013 doesn't even exist. It is VS2013 which comes with the VC++12 compiler. Visual studio names are based on the year they come out, while the compiler versions increment every time. A lot of people make mistakes with this, which sometimes makes it hard to understand.

But the main problem is that tgui seems to be compiled with VC++10 and you are using a newer compiler.
Did you select the right compiler in cmake?
#1788
These errors are completely new to me.

Quotemismatch detected for '_MSC_VER': value '1600' doesn't match value '1700'
This apparently means that you are using a library that was compiled for VS2010 in a VS2012 project.
You can't use a library that was compiled with a different compiler, and libraries from different VC++ versions aren't compatible.

For now I assume that the other errors might be caused by this, so you should first fix this.

QuoteSFML is the release candidate that doesnt require any building.
What do you mean release candidate? If you just downloaded sfml then you have 2.0, or if you dowloaded from github then you have a newer version but then you would have to build it yourself. If you are really talking about the SFML2-RC from last year, then I must say that tgui isn't compatible with that version (but you don't seem to get errors when building tgui so that can't be the case).
#1789
Take a look at the tutorial, if you haven't already.

When your project is in release mode, you need to link with tgui.lib. But when your project is in debug mode, you need to link with tgui-d.lib. On windows then the libraries must always match the build configuration in your project. Thats one of the reasons I prefer developing on linux.

Same time here, but I'm no longer waiting, I'm going to take a nap.

Edit: I overlooked that you are linking statically. But that way you can't get any errors about missing dlls. Are you sure you have SFML_STATIC defined? Also when linking statically to sfml you must do the same to tgui, so use the tgui-s.lib and tgui-s-d.lib libraries.
#1790
I just looked up the error and it is thrown when creating a string that is longer than the maximum string size. I doubt that this is the case here.

Are you sure that you are not mixing release and debug libraries? This can cause strange things with strings.

If that's not the case, could you upload the project so that I can see if everything was set up correctly and possibly test it myself? I won't be able to do that before tomorrow (or maybe I should say until later today, as it has already passed midnight here).
#1791
Help requests / Re: arrays on 30 editBoxes
23 July 2013, 20:19:05
Quote// i never used  EditBoxNames.push_back(editBox);
Well thats your problem.
If you never insert the edit boxes then the EditBoxNames is empty.

And then
Group1Names[i] = EditBoxNames[i]->getText();
should also be
Group1Names.push_back(EditBoxNames[i]->getText());
#1792
Help requests / Re: arrays on 30 editBoxes
23 July 2013, 19:11:15
It looks to me like you are never actually creating the edit boxes.
The segfault makes me believe you are trying to access elements that you didn't insert in the vector.
You try to access 30 elements in the vector, but are there 30 elements in it?

There should be something like this somewhere in your code.
for (unsigned int i = 0; i < 30; ++i)
{
    tgui::EditBox::Ptr editBox(*Group1);
    editBox->load("TGUI/widgets/Black.conf", "Ime" + tgui::to_string(i+1));
    // ...

    EditBoxNames.push_back(editBox);
}


Edit:
You should start counting from 0 instead of from 1. If your names of your edit boxes start counting from 1 then you can still use to_string(i+1), but to access elements in a vector you should start with element nr 0.
#1793
Help requests / Re: arrays on 30 editBoxes
23 July 2013, 16:20:21
You indeed needed tgui::to_string and not just to_string (I overlooked that).
The only reason that tgui::to_string exists is in case you don't have c++11 support, because when you do you could just use std::to_string (it doesn't make a difference).
Technically, gcc 4.6 already supports c++11 with the "-std=c++0x" flag, but I provided a to_string function in tgui so there isn't really a need to use it.

QuoteI get error  no match for 'operator=' in 'Group1Names.std::vector<_Tp, _Alloc>::operator[] [with _Tp = tgui::SharedWidgetPtr<tgui::EditBox>, _Alloc = std::allocator<tgui::SharedWidgetPtr<tgui::EditBox> >, std::vector<_Tp, _Alloc>::reference = tgui::SharedWidgetPtr<tgui::EditBox>&, std::vector<_Tp, _Alloc>::size_type = unsigned int](i) = tgui::EditBox::getText() const()'|
It seems to be an error in the line below.
Group1Names[i] = EditBoxNames[i]->getText();

This isn't correct. You're trying to assing a string to an edit box. I think this should solve the problem.
Group1Names[i]->setText(EditBoxNames[i]->getText());
#1794
Help requests / Re: arrays on 30 editBoxes
23 July 2013, 11:49:05
You don't need to write quotes around the function calls.

You aren't executing the code. You're code is just like this (and hopefully you see that this won't work).
Name[i] = "blablabla";
Group1Ime[i] = "someString";


So replace
EditBoxNames[i] = Group1->get("Ime" + "to_string(i)"); // error here becouse of "", even with Ime[i]
with
EditBoxNames[i] = Group1->get("Ime" + to_string(i));
to remove the error.
#1795
General Discussion / Re: C# binding
22 July 2013, 22:58:58
I looked at what I still had to do and I noticed that you won't have to expect any progress soon.

I don't see a reason for changes like inheriting from the IDisposable class. Unlike sfml which makes calls to the C lib, I made a port and everything should be managed resources. So the code seems finished.
The TextBox won't be written as I will wait for the c++ version to change (the new form builder has a bigger priority).
And copying the c++ documentation is also a lot of work (going from javadoc to the xml docs).
Last but not least, eveything should be tested, but I don't even find the time to do that for the c++ version.

So you can consider the current version as final for now.

The only thing that I actually did in the last few days for the c# version, was buying and setting up a new site for it.
I also added tested the library on a different linux pc and wrote a tutorial for it.
The TGUI.Net library can now be found on tgui.net.

Edit: Some changes that were made in the c++ version in the last weeks aren't in the c# version yet. So there might be another version coming with these changes, but I won't put a date on it. And everything should remain compatible so when the time comes you can just replace the old dll with the new one.
#1796
I don't have the time to look into this right now, but I have a small question.

How do you know when the widgets need to be resized?
The resize event tells that the window gets resized, but because the view stays the same, everything gets stretched by default. The resizing and repositioning should happen when the the view gets changes, right? Then you would have to call some function to resize the gui.

Could you also send me a more full code, because I still don't completely get the picture of how the gui responds exactly.
#1797
Help requests / Re: scrollbar tutorials?
19 July 2013, 20:13:45
Then just use Container* instead of Panel*. Right now I'm just writing example code, not necessary something that can be compiled.
#1798
Help requests / Re: scrollbar tutorials?
19 July 2013, 19:52:20
The line should be
std::cout << callback.widget->getParent()->get("Group1").get() << std::endl;
(which prints the real internal pointer instead of my smart pointer class)

Wait, you made the scrollbar part of Group1 right?
That line assumes that scrollbar is part of the gui. It first asks for the parent (which is supposed to be gui) and then search for the panel called "Group1". But your scrollbar is part of Group1, so when accessing the parent, you already find Group1 and you thus no longer have to search for it.

So change
tgui::Panel::Ptr Group1 = callback.widget->getParent()->get("Group1");
into
tgui::Panel* Group1 = callback.widget->getParent();

As you can see sometimes have to use a normal pointer (*) and sometimes my smart pointer (::Ptr).
This is still a bit of a problem in tgui, but I'll look into this so that in the future everything should work with these smart pointers.
#1799
Help requests / Re: scrollbar tutorials?
19 July 2013, 19:26:27
Right before this line
tgui::Scrollbar::Ptr scrollbar(*Group1, "Scrollbar");
add
std::cout << Group1.get() << std::endl;

On top of your scrollbarValueChanged function add
std::cout << callback.widget << std::endl;
std::cout << callback.widget->getParent() << std::endl;
std::cout << callback.widget->getParent()->get("Group1") << std::endl;


And perhaps add this inside the for loop in scrollbarValueChanged
std::cout << widgets[i].get() << std::endl;

Is any of the things that get printed a null pointer?
The error means that you are calling a function on some null pointer, so somewhere, something isn't initialized properly.
#1800
Help requests / Re: scrollbar tutorials?
19 July 2013, 17:52:10
I see two solutions for the scrollbar.
- You have the scrollbar directly in the gui. When loginScreen or mainScreen is visible, you call scrollbar->hide() and when Group1 becomes visible again you call scrollbar->show().
- You make a different scrollbar inside every groups that need it. This will allow every scrollbar to have its own callback function and to do different things in every group.

The reason why your Group2 doesn't react on the scrollbar, is that you access Group1 in scrollbarValueChanged.
If you could find a way to access the current group, e.g. holding some string that contains either "Group1" or  "Group2" and then use the string like this:
tgui::Panel::Ptr panel = callback.widget->getParent()->get(theString);
Then you can keep the scrollbar in your gui and it will be able to scroll the widgets in whatever group you want by just adjusting the string.