On 04/03/13 13:22, marty moore wrote:
> long i = (long)(w->argument()); compiles, but always results in '0'.
> Doesn't w point back to the Fl_Menu_Button that had the menu?
Probably depends on if you're setting the callback for the widget,
or the callback for the items.
Ea
Hi,
thanks for all the info! I really appreciate the response.
I tried your suggestions on my system: Debian 6.5 (64 bit), gcc-4.4.5, emacs
23, fltk-1.3.2
I tested the following:
eop op = (eop)fl_intptr_t(v); works fine
int i = (int)v; fails to compile (loss of precision) like you all said.
l
On 3 Apr 2013, at 19:38, Richard Sanders wrote:
> When I first compiled with 64 bit linux the compiler complained about
>
> int i = (int)(v);
>
>
> but was happy with
>
> long i = (long)(v);
Greg's suggestion of using fl_intptr_t seems like the most portable option,
should work *everywh
On 3 Apr 2013, at 17:34, Greg Ercolano wrote:
> On 04/03/13 08:44, marty moore wrote:
>> I notice that old examples used
>> int i = (int)v;
>> but that won't work with gcc-4.4.5
>
> Right -- probably a "precision loss" error during the void* -> int,
> since sizeof(void*)==8 and sizeo
On Wed, 03 Apr 2013 09:34:22 -0700, Greg Ercolano
wrote:
>> I notice that old examples used
>> int i = (int)v;
>> but that won't work with gcc-4.4.5
>
> Right -- probably a "precision loss" error during the void* -> int,
> since sizeof(void*)==8 and sizeof(int)==4.
>
> I think t
On 04/03/13 09:05, Ian MacArthur wrote:
>> void mycallback(widget* w, void* v) {
>> eop e = (eop) (atoi((char*)v));
>
> What is it you are trying to do here?
Probably trying to sidestep the 'precision loss' error from the
newer compilers due to sizeof(void*) != sizeof(int).
On 04/03/13 08:44, marty moore wrote:
> I notice that old examples used
> int i = (int)v;
> but that won't work with gcc-4.4.5
Right -- probably a "precision loss" error during the void* -> int,
since sizeof(void*)==8 and sizeof(int)==4.
I think the best approach (in 1.3.x
Assuming this is readable this time... (and not more B64 nonsense...)
> I'm looking at storing an enum as user data in an Fl_Menu_Item user
> data. In the callback, I want to access the enum.
>
> I know that I can put the enum into user data as a string:
> enum eop { task0=200, task2, task3};
>
>
Thanks, I'll try your suggestions.
Marty
> > > dXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLgoqKioqKioqKioqKioqKioqKioq
> > > KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgo=
> > >
> >
> > Thanks for the reply but would you mind translating it? It's unreadable.
> > Mar
Hi all,
Please excuse another newbie question.
I'm looking at storing an enum as user data in an Fl_Menu_Item user data. In
the callback, I want to access the enum.
I know that I can put the enum into user data as a string:
enum eop { task0=200, task2, task3};
Fl_Menu_Item menu = {
{ "thing 1",
> > dXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLgoqKioqKioqKioqKioqKioqKioq
> > KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgo=
> >
>
> Thanks for the reply but would you mind translating it? It's unreadable.
> Marty
Sigh... Sorry about that, I thought that was fixed.
> bWFydHkgbW9vcmUgc2FpZDoNCiANCj4gSGkgYWxsLA0KPiBJIGdldCB0aGUgZm9sbG93aW5nIGVy
> cm9yIHdoZW4gdHJ5aW5nIHRvIGNvbXBpbGUgZmx0azM6DQo+IA0KPiAkbWFrZQ0KPiA9PT0gbWFr
> aW5nIHNyYyA9PT0NCj4gQ29tcGlsaW5nIGZsdGszcG5nL3BuZy5jLi4uDQo+IGZsdGszcG5nL3Bu
> Zy5jOjE0OjIxOiBlcnJvcjogcG5ncHJpdi5oOiBObyBzdWNoIGZpbGUgb3Ig
> Yes, as Edzard says: setting the label of the widget with label() does not =
> *copy* the string, it only retains a pointer to it... which in your case th=
> en drops out of scope and garbage ensues.
>
> I think I'd go with the copy_label() approach myself (which *does* make an =
> internal copy
marty moore said:
> Hi all,
> I get the following error when trying to compile fltk3:
>
> $make
> === making src ===
> Compiling fltk3png/png.c...
> fltk3png/png.c:14:21: error: pngpriv.h: No such file or directory
> fltk3png/png.c:17: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
> ‘__attribute__’ be
Yes, as Edzard says: setting the label of the widget with label() does not
*copy* the string, it only retains a pointer to it... which in your case then
drops out of scope and garbage ensues.
I think I'd go with the copy_label() approach myself (which *does* make an
internal copy of the string)
> 3. When the add menu item is clicked, a new button appears, but has garbage
> text.
Garbage text sounds like a well known problem:
> void set( string str ) { label(str.c_str()); }
label() doesn't copy the string (but there is a copy_label()), but just
saves the given const char*. But yo
16 matches
Mail list logo