From 367f908d8ed5a3464b9676223a26ddf4e11bdb5b Mon Sep 17 00:00:00 2001 From: Michael R Sweet Date: Thu, 7 Jan 1999 16:36:11 +0000 Subject: "Final" changes for first draft of 1.0 documentation. git-svn-id: file:///fltk/svn/fltk/trunk@187 ea41ed52-d2ee-0310-a9c1-e6b18d33e121 --- documentation/osissues.html | 550 ++++++++++++++++++++++---------------------- 1 file changed, 275 insertions(+), 275 deletions(-) (limited to 'documentation/osissues.html') diff --git a/documentation/osissues.html b/documentation/osissues.html index f9cd36991..3e651511e 100644 --- a/documentation/osissues.html +++ b/documentation/osissues.html @@ -1,184 +1,171 @@ -

F - Operating System Specific Issues

F - Operating System Issues - - -Fltk X-specific interface -

Fltk X-specific interface

+This appendix describes the X and WIN32 specific interfaces in FLTK. -#include <FL/x.H> +

X-Specific Interface

-

On Unix/X you can include this file to access fltk's X-specific -functions. Be warned that some of the structures and calls in it are -subject to change in future version of fltk. Try to avoid doing this -so your code is portable. +

-

+On X you can include this file to access FLTK's X-specific functions. +Be warned that some of the structures and calls in it are subject to +change in future version of FLTK. Try to avoid doing this so your code +is portable. -

Handling other X events

+

Handling Other X Events

- -

void Fl::add_handler(int (*f)(int));

extern XEvent* fl_xvent;

extern ulong fl_event_time;

Window fl_xid(const Fl_Window*);

Fl_Window* fl_find(ulong xid);

int fl_handle(const XEvent&);

-

+

Drawing using Xlib

- -

Drawing using Xlib

+The following global variables are set before +Fl_Widget::draw() is called, or by Fl_Window::make_current(): -

-extern Display* fl_display;
-extern Window fl_window;
-extern GC fl_gc;
-extern int fl_screen;
-extern XVisualInfo* fl_visual;
-extern Colormap fl_colormap;

unsigned long fl_xpixel(Fl_Color i);

unsigned long fl_xpixel(uchar r, uchar g, uchar -b);

extern XFontStruct* fl_xfont;

+href="#fl_font">fl_font(). This is not necessarily the +current font of fl_gc, which is not set until fl_draw() is called. -

+

Changing the Display, Screen, or X Visual

- -

Changing the display, screen, or X visual

+FLTK uses only a single display, screen, X visual, and X colormap. This +greatly simplifies its internal structure and makes it much smaller and +faster. You can change which it uses by setting global variables +before the first Fl_Window::show() is called. You may +also want to call Fl::visual(), which is a +portable interface to get a full color and/or double buffered visual. -

Fltk uses only a single display, screen, X visual, and X colormap. -This greatly simplifies it's internal structure and makes it much -smaller and faster. You can change which it uses by setting global -variables before the first Fl_Window::show() is called. -You may also want to call Fl::visual(int), which is a portable interface -to get a full color and/or double buffered visual. - -

int Fl::display(const char *)

extern Display* fl_display;

void fl_open_display();

void fl_close_display();

extern int fl_screen;

extern XVisualInfo* fl_visual;
-extern Colormap fl_colormap;

-

- -

Using a subclass of Fl_Window for special X stuff

+

Using a Subclass of Fl_Window for Special X Stuff

-Fltk can manage an X window on a different screen, visual and/or -colormap, you just can't use fltk's drawing routines to draw into it. -But you can write your own draw() method that uses Xlib calls only. +FLTK can manage an X window on a different screen, visual and/or +colormap, you just can't use FLTK's drawing routines to draw into it. +But you can write your own draw() method that uses Xlib +(and/or OpenGL) calls only. -

Fltk can also manage xid's provided by other libraries or programs, +

FLTK can also manage XID's provided by other libraries or programs, and call those libraries when the window needs to be redrawn.

To do this, you need to make a subclass of Fl_Window and override some of these virtual +href="#Fl_Window">Fl_Window and override some of these virtual functions: -

virtual void Fl_Window::show()

+ +

Fl_X *Fl_X::set_xid(Fl_Window *, Window xid)

+ +Allocate a hidden structure called an Fl_X, put the XID into it, and +set a pointer to it from the Fl_Window. This causes +Fl_Window::shown() to return true. + +

void Fl_X::make_xid(Fl_Window *, XVisualInfo *= fl_visual, Colormap = fl_colormap)

+ +This static method does the most onerous parts of creating an X window, +including setting the label, resize limitations, etc. It then does +Fl_X::set_xid() with this new window and maps the window. -

virtual void Fl_Window::flush()

-

virtual void Fl_Window::hide()

-

virtual void Fl_Window::~Fl_Window()

- +

Setting the Icon of a Window

-

(back to contents) -Fltk MSWindows-specific interface -

#include <FL/x.H>
-Fltk MSWindows-specific interface

+FLTK currently supports setting a window's icon *before* it is shown using +the Fl_Window::icon() method. -The <FL/x.H> header file defines the interface to fltk's -MSWindows-specific functions. Be warned that some of the structures -and calls in it are subject to change in future version of fltk. Try -to avoid doing this so your code is portable. +

void Fl_Window::icon(char *)

+ +Sets the icon for the window to the passed pointer. You will need to +cast the icon Pixmap to a char * when calling this +method. To set the icon using a bitmap compiled with your application +use: + + -

+

WIN32-Specific Interface

-

Handling other MSWindows messages

+ -

A single WNDCLASSEX called "FLTK" is created. All -Fl_Windows are of this class. This window class is created the first -time Fl_Window::show() is called. +The <FL/x.H> header file defines the interface to FLTK's +WIN32-specific functions. Be warned that some of the structures +and calls in it are subject to change in future version of FLTK. Try +to avoid doing this so your code is portable. + +

Handling Other WIN32 Messages

+ +By default a single WNDCLASSEX called "FLTK" is created. All +Fl_Windows are of this class unless you use +Fl_Window::xclass(). The window class is created the first +time Fl_Window::show() is called. -

You can probably combine fltk with other libraries that make their -own MSWindows window classes. The easiest way is to call Fl::wait(), it -will call DispatchMessage for all messages to the other windows. If +

You can probably combine FLTK with other libraries that make their +own WIN32 window classes. The easiest way is to call Fl::wait(), it +will call DispatchMessage for all messages to the other windows. If necessary you can let the other library take over (as long as it calls -DispatchMessage()), but you will have to arrange for the function -Fl::flush() to be called regularily (otherwise widgets will not -update), and timeouts and the idle function will not work. +DispatchMessage()), but you will have to arrange for the function +Fl::flush() to be called regularily so that widgets are updated, +timeouts are handled, and the idle functions are called. - -

extern MSG fl_msg;

void Fl::add_handler(int (*f)(int));

HWND fl_xid(const Fl_Window*);

Fl_Window* fl_find(HWND xid)

+

Fl_Window *fl_find(HWND xid)

-

+Return the Fl_Window that corresponds to the given window +handle, or NULL if not found. This uses a cache so it is +slightly faster than iterating through the windows yourself. - -

Drawing things using the MSWindows GDI

+

Drawing Things Using the WIN32 GDI

-

When the virtual function Fl_Widget::draw() is called, fltk has +When the virtual function Fl_Widget::draw() is called, FLTK has stashed in some global variables all the silly extra arguments you need to make a proper GDI call. These are: -

-extern HINSTANCE fl_display;
-extern HWND fl_window;
-extern HDC fl_gc;
-COLORREF fl_RGB();
-HPEN fl_pen();
-HBRUSH fl_brush();

 -

-

How to not get a MSDOS console window

+ -MSWindows has a really stupid mode switch stored in the executables that -controls whether or not to make a console window (hint to Mr Gates: -why not leave it hidden until the program prints something?). +It may also be useful to refer to Fl_Window::current() to get +the window's size or position. -

To not produce a "console" window when you run your program add the -following secret incantation to the Micro$oft linker: +

Setting the Icon of a Window

-

        /SUBSYSTEM:WINDOWS /ENTRY:mainCRTStartup
+FLTK currently supports setting a window's icon *before* it is shown using +the Fl_Window::icon() method. -

Unfortunately this seems to completely disable stdin/stdout, even -if you run the program from a console. So don't do this until you -have debugged your program! +

void Fl_Window::icon(char *)

-

-

Other hints

+Sets the icon for the window to the passed pointer. You will need to +cast the HICON handle to a char * when calling this +method. To set the icon using an icon resource compiled with your +application use: -

I use capital C as the extension for c++ source code, for instace -for Fluid output. Unfortunately there is no way to convince VC++ to -use this except to tell it to compile *everything* using C++ by -putting the switch "/TP" in the options. This makes it impossible to -combine old C code and fltk code. +

-

-

Known bugs

+

How to Not Get a MSDOS Console Window

-

If program is deactivated, Fl::wait() does not return until it is -activated again, even though many events are delivered to the program. -This can cause idle background processes to stop unexpectedly. This -also happens while the user is dragging or resizing windows or -otherwise holding the mouse down. I was forced to remove most of the -efficiency fltk uses for redrawing in order to get windows to update -while being moved. This is a design error in MSWindows and probably -impossible to get around. +WIN32 has a really stupid mode switch stored in the executables that +controls whether or not to make a console window. -

Fl_Gl_Window::can_do_overlay() returns true until the first time it -attempts to draw an overlay, and then correctly returns whether or not -there is overlay hardware. - -

Cut text contains ^J rather than ^M^J to break lines. This is a -feature, not a bug. +

To always get a console window you simply create a console +application (the "/SUBSYSTEM:CONSOLE" option for the linker). For a +GUI-only application create a WIN32 application (the +"/SUBSYSTEM:WINDOWS" option for the linker). -

I can't seem to get SetCapture (used by Fl::grab()) to work, and I -can't find a way to stop the main window title from turning gray while -menus are popped up. +

FLTK includes a WinMain() function that calls the ANSI +standard main() entry point for you. This function creates +a console window when you use the debug version of the library. -

glpuzzle program does not animate unless you resize it first. Unknown why. +

WIN32 applications without a console cannot write to stdout or +stderr, even if they are run from a console window. Any output +is silently thrown away. -

Fl_Window::fullscreen() not implemented (should take over the screen -without a title bar). Currently does maximize instead. +

Known Bugs

-

Import .bmp files into fluid. Wonko has the specs. +If a program is deactivated, Fl::wait() does not return until +it is activated again, even though many events are delivered to the +program. This can cause idle background processes to stop +unexpectedly. This also happens while the user is dragging or resizing +windows or otherwise holding the mouse down. I was forced to remove +most of the efficiency FLTK uses for redrawing in order to get windows +to update while being moved. This is a design error in WIN32 and +probably impossible to get around. -

Can't set icon of windows. +

Fl_Gl_Window::can_do_overlay() returns true until the first +time it attempts to draw an overlay, and then correctly returns whether +or not there is overlay hardware. +

Cut text contains ^J rather than ^M^J to break lines. This is a +feature, not a bug. +

SetCapture (used by Fl::grab()) doesn't work, and +the main window title bar turns gray while menus are popped up. +

FLUID does not support BMP files yet. + + -- cgit v1.2.3