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__’ before
bWFydHkgbW9vcmUgc2FpZDoNCiANCj4gSGkgYWxsLA0KPiBJIGdldCB0aGUgZm9sbG93aW5nIGVy
cm9yIHdoZW4gdHJ5aW5nIHRvIGNvbXBpbGUgZmx0azM6DQo+IA0KPiAkbWFrZQ0KPiA9PT0gbWFr
aW5nIHNyYyA9PT0NCj4gQ29tcGlsaW5nIGZsdGszcG5nL3BuZy5jLi4uDQo+IGZsdGszcG5nL3Bu
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...
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,
Thanks, I'll try your suggestions.
Marty
dXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLgoqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgo=
Thanks for the reply but would you mind translating it? It's unreadable.
Marty
Sigh...
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};
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) is
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 Wed, 03 Apr 2013 09:34:22 -0700, Greg Ercolano e...@seriss.com
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
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 sizeof(int)==4.
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 *everywhere* I
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.
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.
Each
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2943
Version: 1.3-current
If size of widget is quite small then FLTK draws incorrect rounded box, all
four corners are different (upper fig. on the attached picture).
I
I have found two major bugs in the Mac OS X implementation of Fl_Gl_Window. I
will report the bugs in two separate postings.
The first bug occurs with overlays on Fl_Gl_Windows. If either the OpenGL view
transform or model transform are other than identity, then the code in
The Mac OS X Fl_Gl_Window implementation has a serious bug in the code for
Fl_Gl_Window::make_current when Fl_Windows are nested. The computation for the
x and y values of the xywh array passed to aglSetInteger(context_,
AGL_BUFFER_RECT, xywh) does not take this nesting into account, causing
On 04/03/13 18:34, Lynn Quam wrote:
Since I have not previously reported FLTK bug fixes, I would like
to know the procedure that I should use.
Hi Lynn,
Go to the main fltk.org page and click on 'Bugs Features', and then
click
Submit Bug or Feature Request, and follow the
I have found two major bugs in the Mac OS X implementation of Fl_Gl_Window.
I will report the bugs in two separate postings.
The first bug occurs with overlays on Fl_Gl_Windows. If either the OpenGL
view transform or model transform are other than identity, then the code in
You may need to update your libraries or try another compiler, the program
runs fine on my Ubuntu64 Linux.
Yes it does run fine on my Ubuntu too. The problem are the context creation
when running in Windows7. This is using the FLTK 1.3.2 library, compiled with
the mingw64 gcc compiler
I want to be able to left click in an OpenGL window and have the mouse
coordinates in that window returned (i.e. relative to the upper left corner of
the window). Seems like I should be able to do this using Fl::event_x. However
it's turning out to be difficult. First of all the only way I can
The only idea I have now is to put a large button underneath the OGL window.
When I click inside the OGL window, this button will be activated and I'll
get an x cord. relative to the main FLTK window and have to subtract off the
upper left corner coordinates of the OGL window.
Actually,
21 matches
Mail list logo
