guichan-users Mailing List for Guichan

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Hello!

New message, please read <http://xerox.web.tr/ever.php?wpafa>

an...@bl...

On Sat, May 21, 2011 at 14:56, Olof Næssén <olo...@gm...> wrote:
> SF constantly changes stuff, and one day the wiki broke. I haven't had the
> energy to fix it.

Ok, I understand. What can I do to help with this?, I'm most
interested on the documentation part and the tutorials.

Thanks.
Ernesto

SF constantly changes stuff, and one day the wiki broke. I haven't had the
energy to fix it.

/Olof

On Sat, May 21, 2011 at 4:41 AM, Ernesto Domato <ed...@gm...> wrote:

> Hi, I'd would like to know what happened with the wiki at
> http://guichan.sourceforge.net that seems to not be working.
>
> Thanks.
> Ernesto
>
>
> ------------------------------------------------------------------------------
> What Every C/C++ and Fortran developer Should Know!
> Read this article and learn how Intel has extended the reach of its
> next-generation tools to help Windows* and Linux* C/C++ and Fortran
> developers boost performance applications - including clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Guichan-users mailing list
> Gui...@li...
> https://lists.sourceforge.net/lists/listinfo/guichan-users
>

Hi, I'd would like to know what happened with the wiki at
http://guichan.sourceforge.net that seems to not be working.

Thanks.
Ernesto

Sounds to me like an index out of bounds. What is the standard exception?
When does it occur? To find out where an exception is thrown, remove the
catching of exceptions and let the program crash running inside a debugger.

/Olof

2011/1/26 José Jorge Enríquez <jos...@gm...>

> Hi, I'm using a ListBox inside a ScrollArea for showing a scrollable
> ListBox, it works fine but, when I scroll down to the last element of
> the ListBox, my program crashes showing an standard exception.
>
> I derived from ListModel using this:
>
> class MyListModel : public gcn::ListModel
> {
>        public:
>                std::string getElementAt( int i ) { return m_vector( i ); }
>                int getNumberOfElements() { return m_vector.size(); }
>
>        //~ private:
>                std::vector<std::string> m_vector;
> };
>
> I've just noticed it does not crash only when trying to show the last
> element of the list, but also when just scrolling down some elements,
> I found it when chaning the scroll area height.
>
> Hope someone has found these problems and have a recommendation,
> thanks in advance for your help.
>
> Jose Jorge Enriquez.
>
>
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better
> price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Guichan-users mailing list
> Gui...@li...
> https://lists.sourceforge.net/lists/listinfo/guichan-users
>

Hi, I'm using a ListBox inside a ScrollArea for showing a scrollable
ListBox, it works fine but, when I scroll down to the last element of
the ListBox, my program crashes showing an standard exception.

I derived from ListModel using this:

class MyListModel : public gcn::ListModel
{
	public:
		std::string getElementAt( int i ) { return m_vector( i ); }
		int getNumberOfElements() { return m_vector.size(); }

	//~ private:
		std::vector<std::string> m_vector;
};

I've just noticed it does not crash only when trying to show the last
element of the list, but also when just scrolling down some elements,
I found it when chaning the scroll area height.

Hope someone has found these problems and have a recommendation,
thanks in advance for your help.

Jose Jorge Enriquez.

It has been some time since I worked with guichan, but I seem to
recall I solved this problem in a similar way to the one you describe
without having to hack guichan.

If I recall correctly I had a top level widget which had an empty
render method, and had to do some checks on what was focused when
processing events.

guichan may have changed since then, but as far as I remember I wasn't
replacing components which you normally don't need to replace.

Al

On 15 December 2010 09:22, Per Larsson <fin...@gm...> wrote:
> My idea was to put that functionality into guichan properly, just
> wanted to know if anyone could think of any drawbacks. It sounded too
> easy to me :)
>
> On 15 December 2010 10:04, Jared Adams <jax...@gm...> wrote:
>> On Wed, Dec 15, 2010 at 1:50 AM, Per Larsson <fin...@gm...> wrote:
>>>
>>> How about sending input to the top widget if nothing is focused? Would
>>> that have any drawbacks I can't think of right now?
>>>
>>> On 15 December 2010 06:55, Chuck Miller <sha...@gm...> wrote:
>>> > Hello I am Chuck Miller, I am part of the TMW/ManaSource development
>>> > team.
>>> >
>>> > I am working on some changes on the Mana client, and part of it is to
>>> > improve input handling.  But I have uncovered what seems to be a
>>> > serious usability issue with GuiChan.  But I am posting to the user
>>> > mailing list instead of the developer in hopes that there is a
>>> > solution to this issue.
>>> >
>>> > The issue is somewhat related to this:
>>> > http://code.google.com/p/guichan/issues/detail?id=63
>>> >
>>> > But the issue in a nutshell is that there is no real way to tell if
>>> > application should process input after being handled by guichan.
>>> >
>>> > Imagine you have a game where you use the "awsd" keys to move.   But
>>> > you also have text input boxes.   When a text input box is opened
>>> > these keys should input text.  But if nothing is getting inputted then
>>> > these keys should move the player.  The issue comes in that there is
>>> > no way without heavy overloading classes to determine if they have
>>> > been processed by the user interface.
>>> >
>>> > There are two "half-ass" solutions.  One is that you can have a global
>>> > key listener.  However global listeners are processed before source
>>> > widgets, so there is no way to determine if the source widget is going
>>> > to handle it.   Another option would be to use the "top" widget.
>>> > However if nothing is focused (which seems to happen quite a bit) the
>>> > event will never bubble up to the top widget.
>>> >
>>> > I am hoping that I have just missed some option or method that I can
>>> > use to resolve this issue, but I have looked quite a bit though the
>>> > documentation, and talked with other Mana/TMW developers.  And I can't
>>> > find a clean, solid resolution to the issue.
>>> >
>>> > Your help is greatly appreciated.
>>> >
>>
>> Which requires hacking Guichan or replacing components you normally don't
>> need to replace. Kage is looking for a solution that doesn't require that.
>>
>> ------------------------------------------------------------------------------
>> Lotusphere 2011
>> Register now for Lotusphere 2011 and learn how
>> to connect the dots, take your collaborative environment
>> to the next level, and enter the era of Social Business.
>> http://p.sf.net/sfu/lotusphere-d2d
>> _______________________________________________
>> Guichan-users mailing list
>> Gui...@li...
>> https://lists.sourceforge.net/lists/listinfo/guichan-users
>>
>>
>
> ------------------------------------------------------------------------------
> Lotusphere 2011
> Register now for Lotusphere 2011 and learn how
> to connect the dots, take your collaborative environment
> to the next level, and enter the era of Social Business.
> http://p.sf.net/sfu/lotusphere-d2d
> _______________________________________________
> Guichan-users mailing list
> Gui...@li...
> https://lists.sourceforge.net/lists/listinfo/guichan-users
>

-- 
Alistair Riddoch
alr...@go...
http://alistairriddoch.org/

My idea was to put that functionality into guichan properly, just
wanted to know if anyone could think of any drawbacks. It sounded too
easy to me :)

On 15 December 2010 10:04, Jared Adams <jax...@gm...> wrote:
> On Wed, Dec 15, 2010 at 1:50 AM, Per Larsson <fin...@gm...> wrote:
>>
>> How about sending input to the top widget if nothing is focused? Would
>> that have any drawbacks I can't think of right now?
>>
>> On 15 December 2010 06:55, Chuck Miller <sha...@gm...> wrote:
>> > Hello I am Chuck Miller, I am part of the TMW/ManaSource development
>> > team.
>> >
>> > I am working on some changes on the Mana client, and part of it is to
>> > improve input handling.  But I have uncovered what seems to be a
>> > serious usability issue with GuiChan.  But I am posting to the user
>> > mailing list instead of the developer in hopes that there is a
>> > solution to this issue.
>> >
>> > The issue is somewhat related to this:
>> > http://code.google.com/p/guichan/issues/detail?id=63
>> >
>> > But the issue in a nutshell is that there is no real way to tell if
>> > application should process input after being handled by guichan.
>> >
>> > Imagine you have a game where you use the "awsd" keys to move.   But
>> > you also have text input boxes.   When a text input box is opened
>> > these keys should input text.  But if nothing is getting inputted then
>> > these keys should move the player.  The issue comes in that there is
>> > no way without heavy overloading classes to determine if they have
>> > been processed by the user interface.
>> >
>> > There are two "half-ass" solutions.  One is that you can have a global
>> > key listener.  However global listeners are processed before source
>> > widgets, so there is no way to determine if the source widget is going
>> > to handle it.   Another option would be to use the "top" widget.
>> > However if nothing is focused (which seems to happen quite a bit) the
>> > event will never bubble up to the top widget.
>> >
>> > I am hoping that I have just missed some option or method that I can
>> > use to resolve this issue, but I have looked quite a bit though the
>> > documentation, and talked with other Mana/TMW developers.  And I can't
>> > find a clean, solid resolution to the issue.
>> >
>> > Your help is greatly appreciated.
>> >
>
> Which requires hacking Guichan or replacing components you normally don't
> need to replace. Kage is looking for a solution that doesn't require that.
>
> ------------------------------------------------------------------------------
> Lotusphere 2011
> Register now for Lotusphere 2011 and learn how
> to connect the dots, take your collaborative environment
> to the next level, and enter the era of Social Business.
> http://p.sf.net/sfu/lotusphere-d2d
> _______________________________________________
> Guichan-users mailing list
> Gui...@li...
> https://lists.sourceforge.net/lists/listinfo/guichan-users
>
>

On Wed, Dec 15, 2010 at 1:50 AM, Per Larsson <fin...@gm...> wrote:

> How about sending input to the top widget if nothing is focused? Would
> that have any drawbacks I can't think of right now?
>
> On 15 December 2010 06:55, Chuck Miller <sha...@gm...> wrote:
> > Hello I am Chuck Miller, I am part of the TMW/ManaSource development
> team.
> >
> > I am working on some changes on the Mana client, and part of it is to
> > improve input handling.  But I have uncovered what seems to be a
> > serious usability issue with GuiChan.  But I am posting to the user
> > mailing list instead of the developer in hopes that there is a
> > solution to this issue.
> >
> > The issue is somewhat related to this:
> > http://code.google.com/p/guichan/issues/detail?id=63
> >
> > But the issue in a nutshell is that there is no real way to tell if
> > application should process input after being handled by guichan.
> >
> > Imagine you have a game where you use the "awsd" keys to move.   But
> > you also have text input boxes.   When a text input box is opened
> > these keys should input text.  But if nothing is getting inputted then
> > these keys should move the player.  The issue comes in that there is
> > no way without heavy overloading classes to determine if they have
> > been processed by the user interface.
> >
> > There are two "half-ass" solutions.  One is that you can have a global
> > key listener.  However global listeners are processed before source
> > widgets, so there is no way to determine if the source widget is going
> > to handle it.   Another option would be to use the "top" widget.
> > However if nothing is focused (which seems to happen quite a bit) the
> > event will never bubble up to the top widget.
> >
> > I am hoping that I have just missed some option or method that I can
> > use to resolve this issue, but I have looked quite a bit though the
> > documentation, and talked with other Mana/TMW developers.  And I can't
> > find a clean, solid resolution to the issue.
> >
> > Your help is greatly appreciated.
> >
>

Which requires hacking Guichan or replacing components you normally don't
need to replace. Kage is looking for a solution that doesn't require that.

How about sending input to the top widget if nothing is focused? Would
that have any drawbacks I can't think of right now?

On 15 December 2010 06:55, Chuck Miller <sha...@gm...> wrote:
> Hello I am Chuck Miller, I am part of the TMW/ManaSource development team.
>
> I am working on some changes on the Mana client, and part of it is to
> improve input handling.  But I have uncovered what seems to be a
> serious usability issue with GuiChan.  But I am posting to the user
> mailing list instead of the developer in hopes that there is a
> solution to this issue.
>
> The issue is somewhat related to this:
> http://code.google.com/p/guichan/issues/detail?id=63
>
> But the issue in a nutshell is that there is no real way to tell if
> application should process input after being handled by guichan.
>
> Imagine you have a game where you use the "awsd" keys to move.   But
> you also have text input boxes.   When a text input box is opened
> these keys should input text.  But if nothing is getting inputted then
> these keys should move the player.  The issue comes in that there is
> no way without heavy overloading classes to determine if they have
> been processed by the user interface.
>
> There are two "half-ass" solutions.  One is that you can have a global
> key listener.  However global listeners are processed before source
> widgets, so there is no way to determine if the source widget is going
> to handle it.   Another option would be to use the "top" widget.
> However if nothing is focused (which seems to happen quite a bit) the
> event will never bubble up to the top widget.
>
> I am hoping that I have just missed some option or method that I can
> use to resolve this issue, but I have looked quite a bit though the
> documentation, and talked with other Mana/TMW developers.  And I can't
> find a clean, solid resolution to the issue.
>
> Your help is greatly appreciated.
>
> ------------------------------------------------------------------------------
> Lotusphere 2011
> Register now for Lotusphere 2011 and learn how
> to connect the dots, take your collaborative environment
> to the next level, and enter the era of Social Business.
> http://p.sf.net/sfu/lotusphere-d2d
> _______________________________________________
> Guichan-users mailing list
> Gui...@li...
> https://lists.sourceforge.net/lists/listinfo/guichan-users
>

Hello I am Chuck Miller, I am part of the TMW/ManaSource development team.

I am working on some changes on the Mana client, and part of it is to
improve input handling.  But I have uncovered what seems to be a
serious usability issue with GuiChan.  But I am posting to the user
mailing list instead of the developer in hopes that there is a
solution to this issue.

The issue is somewhat related to this:
http://code.google.com/p/guichan/issues/detail?id=63

But the issue in a nutshell is that there is no real way to tell if
application should process input after being handled by guichan.

Imagine you have a game where you use the "awsd" keys to move.   But
you also have text input boxes.   When a text input box is opened
these keys should input text.  But if nothing is getting inputted then
these keys should move the player.  The issue comes in that there is
no way without heavy overloading classes to determine if they have
been processed by the user interface.

There are two "half-ass" solutions.  One is that you can have a global
key listener.  However global listeners are processed before source
widgets, so there is no way to determine if the source widget is going
to handle it.   Another option would be to use the "top" widget.
However if nothing is focused (which seems to happen quite a bit) the
event will never bubble up to the top widget.

I am hoping that I have just missed some option or method that I can
use to resolve this issue, but I have looked quite a bit though the
documentation, and talked with other Mana/TMW developers.  And I can't
find a clean, solid resolution to the issue.

Your help is greatly appreciated.

Seems like a bug if you ask me. I guess getChildrenArea has to be
overloaded in TabbedArea to return the correct size.

/Olof

On Wed, Oct 6, 2010 at 8:53 AM, Erik Andersson <eri...@gm...> wrote:
> I'm trying to position a widget at bottom right of a tabbed areas container.
> Container *container = new Container();
> container->setSize(tabs->getChildrenArea().width,
> tabs->getChildrenArea().height);
> Button *button = new Button("Log in");
> button->adjustSize();
> button->setX(container->getWidth() - button->getWidth() - 10);
> button->setY(container->getHeight() - button->getHeight() - 10);
> tabs->addTab("Login", container);
> Now the button is half-visible because the getChildrenArea().height returns
> the height of the tabs _including_ the height of the tabs themselves. How do
> I get the childrenArea.height without the height of the tabs included?
> This is what I get: http://i.imgur.com/moLFk.png
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> Guichan-users mailing list
> Gui...@li...
> https://lists.sourceforge.net/lists/listinfo/guichan-users
>
>

I'm trying to position a widget at bottom right of a tabbed areas container.

*Container *container = new Container();*
*container->setSize(tabs->getChildrenArea().width,
tabs->getChildrenArea().height);*
*
*
*Button *button = new Button("Log in");*
*button->adjustSize();*
*button->setX(container->getWidth() - button->getWidth() - 10);*
*button->setY(container->getHeight() - button->getHeight() - 10);*
*
*
*tabs->addTab("Login", container);*

Now the button is half-visible because the getChildrenArea().height returns
the height of the tabs _including_ the height of the tabs themselves. How do
I get the childrenArea.height without the height of the tabs included?

This is what I get: http://i.imgur.com/moLFk.png

On Thu, May 20, 2010 at 05:42, Andrew Yeung <an...@bl...> wrote:
> Hi, does anyone have any examples of creating their own widgets using
> guichan.
>
> In particular how would you draw your own widget?
> Is it just a case of overriding the virtual draw function of the widget
> class?

Yes, that's it. :-)

Some examples from the Mana client:
http://gitorious.org/mana/mana/trees/master/src/gui/widgets

Regards,
Bjørn

Hi, does anyone have any examples of creating their own widgets using guichan. 

In particular how would you draw your own widget?
Is it just a case of overriding the virtual draw function of the widget class?

Regards.
We have an open "issue" about adding SFML,
http://code.google.com/p/guichan/issues/detail?id=105

I haven't got around to do it, and there still might be some stuff
missing, like update our build system.

/Olof

On Wed, Apr 14, 2010 at 5:57 PM, Paulo Mendes <pjm...@gm...> wrote:
> I get it now, thanks for the help :)
>
> By the way, do you know the SFML library (http://www.sfml-dev.org/)? It's
> similar to Allegro, but object oriented and built on top of SDL and OpenGL.
>
> Someone has adapted GUIChan to work with it, which I'm currently using (I
> had to change from Allegro because I was having issues with hardware
> acceleration).
> There's a tutorial for using GUIChan in SFML
> (http://www.sfml-dev.org/wiki/fr/tutoriels/utiliserguichan), unfortunately
> it's only in French,
> Maybe you'd be interested in adding it to GUIChan or referencing it from the
> Wiki.
> (I have no affiliation with any of the above, btw :) )
>
> Anyway, thanks
> Paulo Mendes
>
>
> On 14-04-2010 9:24, Olof Næssén wrote:
>>
>> If you want to draw something outside of the parent, change the draw
>> method to push another  clip rectangle that allows drawing outside of
>> the parent.
>>
>> /Olof
>>
>> On Tue, Apr 13, 2010 at 11:45 PM, Paulo Mendes<pjm...@gm...>
>>  wrote:
>>
>>>
>>> Hi all,
>>> Can anyone help me with the following:
>>> I'd like to have a DropDown draw its contents outside the parent
>>> Container, when it's rolled down (after clicking on it).
>>> The documentation mentions "Widget::showPart" and
>>> "Widget::showWidgetPart", but I can't figure out how to use it.
>>>
>>> Thanks for the help,
>>> Paulo Mendes
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Download Intel&#174; Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> http://p.sf.net/sfu/intel-sw-dev
>>> _______________________________________________
>>> Guichan-users mailing list
>>> Gui...@li...
>>> https://lists.sourceforge.net/lists/listinfo/guichan-users
>>>
>>>
>
>

I get it now, thanks for the help :)

By the way, do you know the SFML library (http://www.sfml-dev.org/)? 
It's similar to Allegro, but object oriented and built on top of SDL and 
OpenGL.

Someone has adapted GUIChan to work with it, which I'm currently using 
(I had to change from Allegro because I was having issues with hardware 
acceleration).
There's a tutorial for using GUIChan in SFML 
(http://www.sfml-dev.org/wiki/fr/tutoriels/utiliserguichan), 
unfortunately it's only in French,
Maybe you'd be interested in adding it to GUIChan or referencing it from 
the Wiki.
(I have no affiliation with any of the above, btw :) )

Anyway, thanks
Paulo Mendes

On 14-04-2010 9:24, Olof Næssén wrote:
> If you want to draw something outside of the parent, change the draw
> method to push another  clip rectangle that allows drawing outside of
> the parent.
>
> /Olof
>
> On Tue, Apr 13, 2010 at 11:45 PM, Paulo Mendes<pjm...@gm...>  wrote:
>    
>> Hi all,
>> Can anyone help me with the following:
>> I'd like to have a DropDown draw its contents outside the parent
>> Container, when it's rolled down (after clicking on it).
>> The documentation mentions "Widget::showPart" and
>> "Widget::showWidgetPart", but I can't figure out how to use it.
>>
>> Thanks for the help,
>> Paulo Mendes
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Guichan-users mailing list
>> Gui...@li...
>> https://lists.sourceforge.net/lists/listinfo/guichan-users
>>
>>      

If you want to draw something outside of the parent, change the draw
method to push another  clip rectangle that allows drawing outside of
the parent.

/Olof

On Tue, Apr 13, 2010 at 11:45 PM, Paulo Mendes <pjm...@gm...> wrote:
> Hi all,
> Can anyone help me with the following:
> I'd like to have a DropDown draw its contents outside the parent
> Container, when it's rolled down (after clicking on it).
> The documentation mentions "Widget::showPart" and
> "Widget::showWidgetPart", but I can't figure out how to use it.
>
> Thanks for the help,
> Paulo Mendes
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Guichan-users mailing list
> Gui...@li...
> https://lists.sourceforge.net/lists/listinfo/guichan-users
>

Hi all,
Can anyone help me with the following:
I'd like to have a DropDown draw its contents outside the parent 
Container, when it's rolled down (after clicking on it).
The documentation mentions "Widget::showPart" and 
"Widget::showWidgetPart", but I can't figure out how to use it.

Thanks for the help,
Paulo Mendes

I would probably create a class inheriting from Container for each
form and have them managed by some manager class. The manager class
could have a method (maybe static?) which hides a container and shows
another given an id (a string) for the container to show. When you
want a button to go to another form, simply make the form listen to
actions from the button and call the manager class to show another
form.

/Olof

On Mon, Mar 22, 2010 at 5:55 AM, Andrew Yeung <an...@bl...> wrote:
> Hi
>
> I've just recently started using guichan with SDL and the visual c++ 2008
> express ide. I've managed to get everything to work and have created some
> very simple test projects using the various widgets. This has gone pretty
> well, however I want to create something a little more complicated and am
> not sure how to go about it. I would like to create a form which has a
> button, pressing the button takes you to a second form which has a textbox
> and a button, this button takes you back to the first form.
>
> How would I go about achieving this.
>
> Regards.
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Guichan-users mailing list
> Gui...@li...
> https://lists.sourceforge.net/lists/listinfo/guichan-users
>
>

Hi

I've just recently started using guichan with SDL and the visual c++ 2008 express ide. I've managed to get everything to work and have created some very simple test projects using the various widgets. This has gone pretty well, however I want to create something a little more complicated and am not sure how to go about it. I would like to create a form which has a button, pressing the button takes you to a second form which has a textbox and a button, this button takes you back to the first form.

How would I go about achieving this.

Regards.
Hi all,

I'm wanting to try to use guichan in a program to compile on OSX - I know there is difficulty building the libraries and the recommendation in the faq is to include the source files in your project - I'm more then happy to do that, but there are a ton of source files including subfolders, and I'm not sure what I need to include and if anything special needs to be done to get it to work...  Anyone that uses OSX/XCode for development, any tips would be appreciated :)

The focus handler has nothing to do with how radio buttons are
selected. Every radio button can get focus from the focus handler. Now
when it comes to selection, radiobutton.hpp contains a static
std::multimap<std::string, RadioButton *> GroupMap meaning it's shared
by every radio button. Each radio button belongs to a group with a
string identifier. Whenever a radio button is selected, the radio
button loops through every other radio button in its group and
deselects the radio button that is selected and finally makes itself
selected.

/Olof

On Thu, Jan 28, 2010 at 11:31 AM, Jorge Vega Sanchez
<mem...@gm...> wrote:
> A la gente le parece bien, mal o que le parece. Contestar please.
>
>
>
> On 28/01/2010, at 0:52, Nicholas J. Kingsley BSc wrote:
>
>> Hello
>>
>> I'm trying to work out how the radio button system works - how does
>> the focus handler know not to de-focus a radio button if the new
>> button isn't in the same group ?
>>
>> The problem is I'm converting Guichan to a version of C that makes
>> STL stuff impossible to use, and whilst I have got radio buttons up
>> and running, I can only have one selected at a time, no matter what
>> group the selected radio button is in.
>>
>> I'm currently using an array of classes, with the class having a
>> group name and an array radio buttons :
>>
>>
>> class multimap {
>>       public:
>>               DGStr                                   group;
>>               DGArray<RadioButton*>   button;
>>       };
>>
>> typedef DGArray<multimap *> GroupMap;
>> static GroupMap mGroupMap;
>>
>> Nicholas
>>
>>
>>
>> --
>> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>> Visit http://www.miscthings.co.uk for great stuff
>>
>> ------------------------------------------------------------------------------
>> The Planet: dedicated and managed hosting, cloud storage, colocation
>> Stay online with enterprise data centers and the best network in the
>> business
>> Choose flexible plans and management services without long-term
>> contracts
>> Personal 24x7 support from experience hosting pros just a phone call
>> away.
>> http://p.sf.net/sfu/theplanet-com
>> _______________________________________________
>> Guichan-users mailing list
>> Gui...@li...
>> https://lists.sourceforge.net/lists/listinfo/guichan-users
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Guichan-users mailing list
> Gui...@li...
> https://lists.sourceforge.net/lists/listinfo/guichan-users
>

A la gente le parece bien, mal o que le parece. Contestar please.

On 28/01/2010, at 0:52, Nicholas J. Kingsley BSc wrote:

> Hello
>
> I'm trying to work out how the radio button system works - how does  
> the focus handler know not to de-focus a radio button if the new  
> button isn't in the same group ?
>
> The problem is I'm converting Guichan to a version of C that makes  
> STL stuff impossible to use, and whilst I have got radio buttons up  
> and running, I can only have one selected at a time, no matter what  
> group the selected radio button is in.
>
> I'm currently using an array of classes, with the class having a  
> group name and an array radio buttons :
>
>
> class multimap {
> 	public:
> 		DGStr					group;
> 		DGArray<RadioButton*>	button;
> 	};
>
> typedef DGArray<multimap *> GroupMap;
> static GroupMap mGroupMap;
>
> Nicholas
>
>
>
> -- 
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
> Visit http://www.miscthings.co.uk for great stuff
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the  
> business
> Choose flexible plans and management services without long-term  
> contracts
> Personal 24x7 support from experience hosting pros just a phone call  
> away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Guichan-users mailing list
> Gui...@li...
> https://lists.sourceforge.net/lists/listinfo/guichan-users

Hello

I'm trying to work out how the radio button system works - how does the focus handler know not to de-focus a radio button if the new button isn't in the same group ?

The problem is I'm converting Guichan to a version of C that makes STL stuff impossible to use, and whilst I have got radio buttons up and running, I can only have one selected at a time, no matter what group the selected radio button is in.

I'm currently using an array of classes, with the class having a group name and an array radio buttons :

class multimap {
	public:
		DGStr					group;
		DGArray<RadioButton*>	button;
	};

typedef DGArray<multimap *> GroupMap;
static GroupMap mGroupMap;

Nicholas

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Visit http://www.miscthings.co.uk for great stuff

2006	Jan	Feb	Mar	Apr	May	Jun (2)	Jul (12)	Aug (1)	Sep	Oct	Nov	Dec
2007	Jan (5)	Feb	Mar (18)	Apr (14)	May (2)	Jun (1)	Jul (7)	Aug	Sep	Oct	Nov (2)	Dec
2008	Jan	Feb	Mar	Apr (1)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2009	Jan	Feb	Mar	Apr (3)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2010	Jan (7)	Feb	Mar (3)	Apr (4)	May (2)	Jun	Jul	Aug	Sep	Oct (2)	Nov	Dec (5)
2011	Jan (2)	Feb	Mar	Apr	May (3)	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2015	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov (3)	Dec (1)
2016	Jan (1)	Feb (2)	Mar	Apr (2)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

guichan-users Mailing List for Guichan

guichan-users — List to be used when discussing usage of Guichan