Frequently Asked Questions

A native port running on top of OS-X w/o the need of an X Server may be a project that will be undertaken at some time in the future; however, please be aware that since the loop and feel is completely determined by FOX's own implementation, a natively ported FOX application will look identical to the one using the X Server.

Which Systems are supported by FOX?

Linux. Any version of Linux should work, on any hardware. FOX is being developed on LINUX.
FreeBSD. FreeBSD is reported to work.
OpenBSD. packages are also available.
SGI IRIX. SGI systems with IRIX 5.3 and up. It can be compiled with GCC or SGI's MIPS Pro C++ compiler.
SunOS/Solaris. Either Solaris or SunOS. Compiled with GCC or Sun Workshop C++.
HP-UX. Tested with GCC under HP-UX 9.x and 10.x.
IBM AIX. Tested with GCC under AIX 4.2.
DEC Alpha/COMPAQ Tru64. Tested with GCC under Digital Unix 4.0.
Other UNIX Systems. If you have a reasonable C++ compiler, UNIX, X11, chances are very good you can get FOX to work.
Microsoft Windows 2000, Windows NT 4.0, Windows 95, Windows 98. Compile either with Visual C++ 6.0, Borland C++ Builder, CYGWIN32, MINGWIN32, and IBM VisualAge C++ for Windows. Older versions of Visual C++ will work, but you must create your own projects in that case.

These are the systems we know about. Since FOX uses GNU autoconfigure, chances are good that most UNIX/X11 combinations can be made to work. If you're running FOX under a system not mentioned above, please drop me a line so we can add it to the list.

Is FOX `64-bit clean'?

yes

While coding of FOX itself has been prepared for the coming 64-bit era, the same may not be true for your own application code. A few guidelines:

Most systems (except Microsoft) follow the ILP32 vs LP64 model, i.e. in 32-bit mode integers, longs, and pointers are 32-bits, and in 64-bit mode longs and pointers become 64-bits while integers stay 32-bit. Microsoft seems to continue with long equal to 32-bit even for 64-bit CPU's.
If you use the FOX types like FXlong and FXint the sizes are going to be typedef-ed properly according to the LP64 model.

On some 64-bit compilers, a double-cast may be needed for casting pointers to an int via long. For this purpose, FOX defines a signed and unsigned integer type whose size is big enough to fit a pointer.
These types are called FXival and FXuval. Note that FXival and FXuval are defined to be the size of a pointer, and so these are not fixed-size types to be used for streaming!
For portable code you will need to cast void* to FXint by way of FXival or FXuval, as in:
```
intval=(FXint)(FXival)ptr;
```
Conversely, its a good idea to cast from FXint to void* by way of FXival or FXuval to get predictable zero-extended or sign-extended results:
```
ptr=(void*)(FXuval)intval;
```
You should use the FXint, FXlong, etc. types when serializing data using FXStream. The types FXint, FXlong, etc. are defined to be a certain size and are the same on all architectures; otherwise binary data will not be compatible between platforms.

Of course all the usual caveats apply, like using sizeof() instead of hard-coded assumptions about sizes; the best practice of developing portable code is to develop it on a number different platforms from the very beginning.

How do I write portable code?

own code

Don't include any platform-dependent libraries (e.g. no "Windows.h" or "X11.h". Just your regular stdio, stdlib and so on (those are C/C++-language standard libraries, and pretty much the same on most machines except for some minor nitty gritty stuff.

Of course, you will use FOX, and while your own code isn't platform dependent, FOX itself is. So you *will* have to link your application with various platform-dependent libraries that FOX itself uses.

You can safely assume sizes of FXchar, FXshort, FXint, FXlong, FXfloat and FXdouble to be the same on all platforms. However, int, long, etc. are NOT guaranteed to be a certain size. This is important when saving loading binary data files (e.g. using FOX's FXStream class). Also, there is byte-order. This is also platform-dependent. FXStream allows for byte swapping during I/O. The symbol FOX_BIGENDIAN is set 1 on big-endian machines (e.g. SGI, PPC) and 0 for little-endian machines (Intel, Alpha).

To be 64-bit future-proof, you *must* use double-cast to- and from pointers. see above. Just to be sure.

Try avoid very sophisticated C++ features (this means most of STL). Code that does a lot of STL doesn't port one iota's worth, at best it compiles with thousands of warnings [some people are going to flame me for this, but its true!].

Use FOX macros like FXMALLOC(), FXFREE() and so on. They are implemented to behave EXACTLY the same on all systems (even though underlying malloc() and realloc() library functions don't always treat the corner cases properly.

Use FXTRACE(()) for debugging; use FXASSERT for asserts. Use fxwarning fxerror() and fxmessage() for messages to the console (on Windows, you don't have a console, and printf() will crash!!). These functions "do the right thing" on the various platforms.

Don't try to do your own filename manipulation routines. Use the functions in the FXFile namespace. These functions properly handle drive letters, Windows Uniform Naming Convention, and so on. They also know about forward and backward slashes and such stuff. Use the PATHSEP, ISPATHSEP etc. macros to check for path separation characters.

Do not assume characters are signed or unsigned; FXuchar is always unsigned, however, FXchar may be either.

When opening a binary file, don't forget fopen("name","rb") instead of fopen("name","r"). On UNIX there is no difference, but on Windows, forgetting the "b" will cause "\r\n" to be translated to "\n", corrupting the data stream.

Why do I get an `illegal icon specified' message when I change some Widget's icon?

client-side

server-side

The C++ constructor of an object only builds the part in the client side. The server side part of the Icon [Widget, Image, etc] is realized when you call create() on it. For convenience, all reachable resources may be created with a single call to FXApp::create(). The call to FXApp::create() traverses the entire Widget tree and creates all Windows, Icons, and other resources that are needed to realize that Widget tree on the screen.

The reasons for all this are:

Since all FOX classes may be subclassed, it cannot be assumed that after an object's ctor has run that the object has been fully constructed; after all, you may have subclassed it.
It will also be important later on when the GUI itself will be subject to serialization. As we can not serialize server-resident resources, we need a two-step process of construction [via deserialization] and creation [from a single call to FXApp::create()].

Because of this, when you construct an FXIcon later on, then you need to call FXIcon::create() manually, as the icon was not a part of the Widget tree at the time the Widget tree was first realized.

Compiling FOX as a DLL under VC++ gives me a unresolved external symbol?

-DFOXDLL

Of course, you can also build FOX as a static library, in which case there is no problem.

When do I call flush(), forceRefresh(), refresh() and update() after a change?

lazy

freeze/thaw

There are several aspects to this: repainting the screen, i.e. processing expose or repaint events, performing layout computations, and performing GUI updating.

Repaint Events are piled up until there are no further events to be processed. In fact, repaint events are not simply saved but are conglomerated into larger and larger rectangles, so as to minimize the number of times that repainting is actually done (it actually also minimizes the area which is repainted).
Layout Reconciliation is also delayed. No layout is performed until returning to the event loop, in fact. Like repainting, layout is delayed until no more events are available.
GUI Updating is also delayed until there are no more events in the queue.

The order in which these are performed are repaints, layout, and gui-updates. Contrary to intuition, delaying the expensive operations such as repainting instead of doing them right away is actually faster.

Sometimes, you want to force the display to refresh without returning from a callback; this can be effected with the following routines:

FXApp::flush() will flush all drawing commands to the display. In other words, it will cause all drawing commands to be executed eventually. Note that flush() is moderately expensive as it causes synchronization between the display and the program.
FXApp::forceRefresh() will perform a layout reconciliation, followed by a GUI update. Since this may lead to more expose events, you typically follow a call to forceRefresh() with a call to flush(). Note that forceRefresh() is a very expensive operation.
FXApp::refresh() is similar to forceRefresh() in that it causes a layout and a GUI update to be performed. The difference is that refresh() will not actually perform the operation but simply cause the system to perform layout/gui-update later, after returning to the event loop. The call to refresh() is very cheap.
FXWindow::update() marks the window, or part of the window as dirty. This causes the window to receive an expose event at some point in the future. The rectangles marked with update() as dirty may be conglomerated into a few big rectangles. No repainting is actually performed until returning to the event loop or calling flush(). Since no drawing is performed, a call to update() is fairly cheap.
FXWindow::repaint() performs the opposite of update(). It paints the window, or part of the window by issuing SEL_PAINT messages if necessary. It works by first pulls all outstanding expose events from the X server, compositing the dirty rectangles. Then, it processes all dirty rectangles pertaining to the given window; if a rectangle is passed, it only processes the dirty rectangles overlapping with the given rectangle. Note that repaint() should NOT be called while performing a painting operation as it would lead to multiple locks of the device context FXDCWindow.
FXApp::repaint(), does the same as FXWindow::repaint(), except FXApp::repaint() causes ALL windows to process their backlogged SEL_PAINT messages.
FXWindow::recalc() marks the widget, and all of its parents, as dirty, i.e. in need of layout. Under normal circumstances, layout is only called when the size of a widget has changed; however, there are often other reasons why layout is needed. In such cases, calling recalc() will ultimately cause a layout to happen also. The entire chain from the widget to its top most parent must be marked this way, otherwise (as there may have been no size changes), the layout process will stop. A few widgets will overload recalc() to cause additional layout computations to happen (e.g. computing content size inside a scrolled view of a list).

How does layout work, exactly?

But automatic placement takes a bit of getting used to, especially for Windows developers who are not accustomed to the concept (many UNIX GUI systems such as Xt and Motif have similar layout facilities so UNIX programmers tend to be more familiar with the idea).

Composite widgets may contain one or more child widgets. These child widgets could be simple controls, like Buttons, but also other Composite widgets. Thus, layout is inherently a recursive process.
Layout of a widget tree is determined by the following:

The arrangement pattern. For example, a Matrix layout manager arranges the children in rows and columns; a HorizontalFrame arranges its children side by side, and a Packer arranges them against the sides of the interior.
The packing flags. A layout manager has certain flags which apply to the layout of all of its children. For example the flag PACK_UNIFORM_WIDTH causes each child to be made the same width.
The layout hints. Each child has certain layout flags which affect the way the layout manager places that child; an example is the LAYOUT_FIX_WIDTH flag which tells the layout manager of that child that the child wants to keep its initially assigned width instead of its minimum (default) width.
Not all layout hints are observed by the layout manager; certain arrangements interpret certain hints, and ignore others. For instance the Switcher layout manager places all children on top of each other, and makes them all the same size.
Other information, such as the interior padding between the edges of the layout manager and its children, spacing between children, and other information like the number of rows and columns in a Matrix layout manager, or which child is on top in a Switcher layout manager, and so on.

The widget's size has changed in response to position() or resize().
The widget has been marked as dirty by means of recalc().
In a few cases, layout() is called directly.

Only a handful of API's are responsible for the whole layout process:

getDefaultWidth() and getDefaultHeight(). These API's measure the minimum size of the widget. For simple controls such as Buttons the implementation consists of simply adding up the size of the icon, caption, and surrounding borders.
For layout managers however, it is more complex:- the size of the layout manager depends on the arrangement, and the size of the children, and needs to take into account the packing flags and layout hints as well.
getWidthForHeight() and getHeightForWidth(). These measure the width of a widget in terms of its height, and the height of a widget given its width, respectively. In order for getWidthForHeight() to work, the height has to be known in advance.
Because of these restrictions, these functions are basically only called from top level windows, as top level windows are given a size directly by the user and therefore the required information is known.
position(). This API physcally moves a child's to its new location, and if the child's size was changed or the child was marked as dirty, recursively invokes layout() on the child.
layout(). This is the workhorse of the layout system. The typical implementation in a layout manager loops over all the children, applying each child's layout hints and default size as computed by getDefaultWidth() and getDefaultHeight(), and then placing each child accordingly by calling position(). Note that by calling position(), the child's layout() may in turn be called!

When I construct a window at the beginning it works but when I construct it later it doesn't

FXApp::create()

window->create()

Please refer to the section about creating icons for a more detailed explanation.

About numbering Message ID's.

class MyDialog : public FXDialogBox {
  ...
  enum{
    ID_CLICKED_YES=FXDialogBox::ID_LAST,
    ID_CLICKED_NO,
    ID_CLICKED_OK,
    ID_CLICKED_CANCEL,
    ID_CLICKED_QUIT,
    ID_CLICKED_SAVE,
    ID_LAST
    };
  ...
  };

As you see, the implementor of the base class can insert additional message ID's but the numbering is automatically kept straight by the compiler. Also, if you're own class is being derived from then this derived class can start counting from MyDialog::ID_LAST and not worry about any messages being inserted into MyDialog.

Why Support GIF!

From what I've read, LZW decompression is not subject to the patent [hence ability gzip support for the old ``compressed'' files].

I feel that there is therefore no need to remove the FOX support for GIF icons/images, and therefore any existing investment should you have in large icon collections would be protected.

Should you still harbor any qualms about using GIF's in your project, you could of course always use BMP icons. However, GIF icons appear to be typically about half the size of BMP icons.

Note that the LZW patent will expire soon, and so compressed GIF support will therefore be reinstated.

Nevertheless, software patents are very bad for software developers, particularly since so many completely trivial ideas seem to slip through the patent system.

Failing to delete menu panes in owner's destructor.

owner

When adding a MenuCommand in a MenuPane, the MenuCommand will obtain the owner of the MenuPane and install its accelerator in the owner's accelerator table. This is necessary, as the accelerator is to be effective without the MenuPane being having been popped up.

When the MenuCommand is destroyed, it tries to remove this accelerator again by obtaining the MenuPane's owner and removing the accelerator from the owner's accelerator table. Should it be the case that the owner of the MenuPane had already been deleted, an access to a non-existing memory location (segmentation fault) will likely occur.

Thus, it is necessary for the owner of a MenuPane to be still in existence when the MenuPane itself is destroyed. So when the owner of a MenuPane is destroyed, it must make sure the MenuPane is destroyed before its destructor completes:- otherwise, the MenuPane would refer to a non-existent owner.

As a general rule, shared resources such as Icons, Fonts, Cursors, Bitmaps, and also MenuPanes, must be explicitly deleted by the widgets that owns them.

How does FXStream serialize an FXObject?


  // Declarations
  FXStream    stream;
  FXDocument *document;

  // Serialize
  stream.open(FXStreamSave);
  stream << document;
  stream.close();

  // Deserialize
  stream.open(FXStreamLoad);
  stream >> document;
  stream.close();

serialize

stream checks an internal hash table to see if document has been serialized before.
if it has been serialized before we just save a reference number into the stream, and we're done.
if document was not encountered before, stream saves the classname.
then, the document->save(stream) is called to save the object's contents [member data] into the stream.

When you deserialize an object is:

stream loads an item from the stream.
if the item represents a reference number, then we must have loaded the document previously; using an internal lookup table, stream maps reference number to the memory address where document was loaded, and returns this address.
if the item is a classname, then stream calls FXMetaClass::getMetaClassFromName(classname) to obtain the metaclass, and calls metaclass->makeInstance() to properly manufacture an object.
then, stream calls document->load(stream) to pull in the object's contents.

Sometimes, a special container object is referred by other objects, but should not itself be serialized. In this case, you may want to use the constructor:

  FXStream    stream(container);

instead. This will add the pointer container to the internal table of stream, so that any subsequent encounter of the same pointer value will generate a reference number only.

Why did FOX choose the message-map based callback paradigm

connect

sources

targets

Function pointer [Motif, Xt].

Very dissatisfying for C++ programs, as it is not object-oriented.
Extra callback parameter [call_data] is not type safe.
This is mostly interesting for procedural programming styles, e.g. using C.
Hard to serialize (or save to file) the connectivity.

Message handling with fixed routing [Microsoft Foundation Classes, Borland C++ Builder].

Can bind source and target together at run time.
Need fixed message routing scheme, since there is no specific target.
Need to keep the messages globally unique (because of the fixed message routing scheme).
Message-delegation [forwarding of messages to another party] is easy.
GUI widgets can not receive messages, only sent them (because of a fixed message routine scheme).
May be not type-safe.
Easy to serialize the connectivity.

Signal/Slot [Qt (Preprocessor), C++ templates (Gtk--, I believe)].

A special preprocessor does not seem very elegant to me [Qt].
A template-based signal/slot system is elegant from a theoretical point of view.
Templates are instantiated at compile time. This means it's going to be difficult to hook up objects which are only known at run time [like e.g. loading a custom control from a DLL].
To connect a message source and a target, you actually construct a connector object that is parameterized by the target; you can not do this unless you know the type of the target [This is because pointer-to-member-of-class types can only be downcast!].
Hard to serialize, because a pointer-to-member-of-class contains a function-pointer when the member is not a virtual.

Message handling with specific target [FOX, NeXTSTEP (using Objective-C of course)].

You can connect at run-time, because connectivity does not involve compile-time code generation like with a signal-slot mechanism. Run-time connectivity is needed because you may load objects dynamically from a DLL, from deserialization, or you may want to write an GUI-Builder which interactively connects things up.
There is no need for a globally unique list of message ID's. The message is addressed to a specific target, and the same message-ID can be reused by another target for another purpose.
Widgets may receive messages as well as send them. This is very important for component-based programming paradigms. It is also important to note that this allows for ``glue-less'' programming; for example, a message ID_HIDE to any Control will hide the Control.
No special preprocessor is needed. The compiler automatically keeps the message-ID's straight [see above].
It is not type safe, in the sense that if you do need to interpret the void*, you would need to cast. Note however that in the vast majority of cases, the void* argument is not used; when it is used, the use is pretty consistent:- what do you think the void* refers to when the message-id is ID_SETINTVALUE?
In the case of NeXTSTEP, the argument signature was a part of the message, which means that for an object to implement the message, the signature had to match up; this was type-safe while at the same time very flexible.
Alas, FOX was written in C++, not Objective-C.
You connect things simply by passing the target-pointer in the constructor when you create a widget.
FOX supports message delegation very easily.
You can actually turn FOX into a type of template-based signal/slot system of you make FXObject-derived connectors!

very compact

run-time connectivity

component-oriented

Why does a AUTOGRAY disable, but not enable the Button?

AUTOGRAY

AUTOHIDE

not

I get compiler errors in Visual C++ when inclusing FXArray or FXElement

placement

new

  #include < new >

fx.h

My Motif application complains with messages about failing to allocate colors

colormap

color palette

The simplest way is to specify the maximum number of colors on the command line, with the parameter -maxcolors n. The number n should be between 2 and 256. Setting the parameter causes FOX to allocate no more than the indicated number of colors. FOX will attempt to allocate a block of colors such that nRed x nGreen x nBlue is not larged than n; it will favor slightly more resolution in the green and red than in blue, because the eye is more sensitive to these colors.
If you find yourself passing this parameter regularly, you may consider specifying the number of colors using the Registry mechanism instead; this way, FOX applications will automatically pick this up. The most easy way to do this is to load the file $HOME/.foxrc/Desktop into your editor, and adding the following to the [SETTINGS] group:
```
[SETTINGS]
maxcolors = 64
```
Of course you may specify any number you like.
The last method is to specify the maximum number of colors programmatically. In case you're developing e.g. a data-entry application, you may not need many colors and you can simply set the value to a fairly low value, like 27:
```
FXVisual *vis = application->getDefaultVisual();
vis->setMaxColors(27);
```
Of course you will need to do this prior to a call to application->create().

File fxpngio.cpp does not compile on IRIX 6.5

GNU

Re-run configure as configure --disable-png to disable PNG image file support. FOX will be fully functional, except that PNG image file support is stubbed out.
Obtain the PNG library libpng version 1.05 or better, and install this on your machine.
You can find PNG on: http://www.libpng.org/pub/png/.

Developing FOX Applications under Windows.

here

Why are there various flavors of running an event loop?

FXApp::run(). This is the main event loop and it is entered when you start your program, and does not exit until you call FXApp::exit(), or the application object receives the ID_QUIT message. Typically, after returning from FXApp::run() your program will exit.
FXApp::runModalFor(window). You enter this event loop to run a modal dialog. A modal dialog is a dialog which will block any interaction with any other window of the program except for the indicated dialog window, until the modal event loop is exited.
FXApp::runModalFor() is a recursive invocation of the event loop, and it will not return until FXApp::stopModal(window,code) is called. The return code is passed along and will be returned by FXApp::runModalFor().
FXApp::runModalWhileShown(window). This routine is a variant of FXApp::runModalFor() which returns as soon as the window is no longer visible, or until terminated by FXApp::stopModal().
FXApp::runUntil(condition). This routine enters a recursive event loop, passing all events normally. The event loop returns as soon as the variable condition is set no a non-zero value.
FXApp::runWhileEvents(). This routine enters a recursive event loop, but returns as soon as no current events are outstanding in the event queue. This can be used to catch up with the event stream during processing of some long computation, and then resume the computation as soon as all events have been processed.
FXApp::runOneEvent(). This function processes one single event and then returns.
FXApp::peekEvent(). This tests if any events are present on the event queue, and returns immediately with TRUE if there are, or FALSE otherwise.

Recursive invocations of the event loop are very useful, because they allow you to temporarily resume processing of events without returning from your message handler.
The runModalFor() is especially useful if your message handler needs to display a temporary dialog box, acquire some information from a user, and then continue processing the user input all without returning to the main event loop.

Why do I need to declare a default contructor in my classes?

FXDECLARE()

(.h)

FXIMPLEMENT()

(.cpp)

metaClass

getMetaClass()

manufacture()

default constructor

manufacture()

getMetaClass()

metaClass

A default constructor needs to be defined in your class because the manufacture() function needs to use the default contructor to create a properly initialized object of this type. This is needed by the deserialization system so that it can allocate and initialize an object prior to loading values for the persistent member variables.

Which FOX objects do I need to delete to avoid memory leaks?

Cursors, Fonts, Images, Icons, Bitmaps, and Visuals are sharable resources which must be cleaned up explicitly. Because several Widgets may refer to the same icon or font, these resources are not automatically deleted by the Widget as they may be used in another Widget. A number of resources, such as the default cursors, the default font, and the default visual, are automatically created by the Application object, and the Application object also assumes responsibility to destroy these when the Application object itself is being destroyed.

Menu panes usually refer to the Widget that owns them, and because dangling references to a deleted owner object are not allowed, the owner Widget must make sure the Menu panes are deleted when the owner Widget itself is. Failing to do this will leave the Menu pane in existence while their owner is already deleted, and this will cause problems.

Ordinary Widgets, like Buttons, Sliders, and so on, are automatically deleted by their parent Widget; therefore it is not necessary for your application to keep track of them explicitly

What's the difference between detach and delete?

X-Server

GDI

create()

destroy()

create()

destroy()

fork()

handles

detach()

destroy()

Can I use multiple threads in my FOX application?

always the same thread

You can however use any number of threads in your application, as long as they are worker threads, i.e. they do not perform User Interface functions.

Synchronization between the User Interface thread and the worker threads can be performed using a synchronization object, a pipe (UNIX/LINUX) or an event object (MS-Windows).

The synchronization object is passed to FXApp::addInput() so that the User Interface thread is awakened when the worker thread turns the synchronization object into a signalled state.

In the more recent FOX versions (FOX 1.7 and newer), a facility has been implemented called FXMessageChannel to make this easier. Using FXMessageChannel, a worker thread can send an asynchronous message to the GUI thread, causing it to wake up and dispatch to a handler in order to process a message on the worker thread's behalf. (Older versions of FOX used FXGUISignal, which is a more limited form of this facility).

Can I cross compile FOX on Linux for Windows?

Markus Fleck

  FROM: Markus Fleck
  DATE: 04/10/2001 09:42:55
  SUBJECT:  [Foxgui-users]Convenient cross-compiling for Win32 on Linux



  Hi!

  Below are some experiences that I thought I'd share; they're mostly of
  interest if you're a UNIX developer at heart and are forced to create Win32
  versions of your applications as well (using FOX for the GUI part, of
  course :-).

  I'm currently using FOX for cross-platform development (Linux and Win32),
  and have been using Cygwin under Windows for some time to create binaries
  for Win32. Unfortunately, Cygwin under Windows is quite slow, and tends to
  crash rather often (at least for me.)

  Recently, I came across a patched GCC cross-compiler for Win32:

    http://www.libsdl.org/Xmingw32/

  A Linux binary build of the cross-compiler can be downloaded from that site,
  or you can use the script at

    http://www.libsdl.org/extras/win32/cross/build-cross.sh

  to automatically download, configure and build the cross-compiler from
  sources for your platform.

  The cross-compiler works like a charm; I am now able to create Win32 .EXE
  binaries in a fraction of the time that Cygwin used to require running under
  native Windows.

  Using the cross-configure.sh/cross-make.sh scripts as a starting point, even
  "configure" and "make" can be run on Linux, even though you're generating
  target code for the Win32 platform.

  I have also started to make use of "Wine" (the Linux/FreeBSD-based execution
  environment for Win32 EXE/DLL code) instead of booting into Windows for the
  purpose of testing my application; I had to uncomment (or "#if 0") the call
  to "TrackMouseEvent" in FOX's src/FXApp.cpp, though, because apparently Wine
  doesn't implement that function and aborts when it encounters a call to it.

  I also had to disable (or actually, comment out using "dnl") the invocation
  of autoconf's "AC_C_BIGENDIAN" macro in configure.in (and invoke "autoconf"
  to rebuild the "configure" script); it appears that "AC_C_BIGENDIAN" doesn't
  (yet) accept a default endianness value to use when cross-compiling, so that
  effectively the "AC_C_BIGENDIAN" test cannot be used when cross-compiling
  (yet). So in order to better support cross-compiling, configure.in should
  probably test for "ac_cv_prog_cc_cross=yes" and/or shortcut the endianness
  test if Win32 is the target platform.

  In a nutshell, I can only recommend using the GCC cross-compiler to build
  Win32 executables; it's much faster than Cygwin and much more convenient if
  you prefer to do development on a UNIX-type system. If you're using Linux
  or FreeBSD, "Wine" can give you some additional convenience when it comes
  to testing you application.

So cross compiling is not only possible, but it works very well and may be faster than working natively. One note on the AC_C_BIGENDIAN thing:- you can simply pass -DFOX_BIGENDIAN=0 on the compiler command line to override it.

Can I have other colors besides black and white for my cursor?

As of FOX 1.1.45, yes! Under X11, you will need the Xcursor extension, which means you must have a recent X server such as XFree 4.3 or later. On Windows, it should be OK in all cases.

Why is the SEL_DELETED message sent before the actual deletion?

save

prior

undo

How do I perform double buffered drawing?

  picture=new FXBMPImage(getApp(),NULL,IMAGE_SHMI|IMAGE_SHMP,500,500);
  ...
  picture->create();
  ...
  FXDCWindow dc(picture);
  dc.setBackground(FXRGB(255,255,255));
  dc.drawRectangle(0,0,500,500);        // Erase it!
  ...
  ... drawing commands ...
  ...

And in onPaint:

  FXDCWindow dc(this,(FXEvent*)ptr);
  ...
  dc.drawImage(picture,0,0);
  ...

How do I make sure drawing is flicker-free?

Limit drawing to the dirty area. Use FXDCWindow dc(this,event), because that will clip all drawing commands to the event's dirty rectangle. Drawing takes more time that almost anything else; so it is worth a lot of work to limit the amount of drawing. I refer to FXTable to give you an idea. Drawing the table seems simple enough, but initially it was very slow. I've since then expended a lot of code to determine which cells of the table were clobbered, and for each cell set clipping rectangles so as to not erase the grid lines. Now the table is virtually flicker free, and draws a whole lot faster.

Try to avoid erasing the background of the entire widget. Instead, paint background around the content area, then paint the content over. This is done in most FOX widgets, particularly FXTable.

If you have to erase the background, try and erase it little bits at a time. For example, in the FXList widget, instead of erasing the entire widget and then painting the icons over it, I erase and paint over each item individually. While is is actually a bit slower, it is visually much more acceptable because at no time is the entire widget completely erased.

Flush the command buffer prior to the erase, and after the last drawing command which paints over the erased background. Drawing commands are buffered, and the buffer is flushed when it is full. However, you don't want to have the situation where the last command sent is the erase, as in that case the window will stay white for the entire duration while the command buffer is filled up with commands to paint over the background. You want the erase command and the paint command to be in the same batch, if possible, so that they get executed by the X server right after each other.

Perform double-buffered drawing, using an FXImage as noted above.

Why does the border style not follow what I specify?

Under X11, the decorations are mere Hints to the Window Manager. Different Window Managers may or may not observe the hints properly. As the Window Manager is a program written by other people, I have little influence over their correctness in observing the decoration hints.

However, I have had fairly good luck with Motif, KDE 2.2, and other Window Managers like WindowMaker, Sawmill, BlackBox, and Enlightenment.

The Free Desktop Project is trying to standardize various aspects of client and Window Manager interaction, and FOX will try to take advantage of this where it makes sense.

What's the deal with default buttons?

default buttons

One single button in the dialog box may be designated as the initial default button. The initial default button is the one that will become the default button whenever the focus moves to a widget which can not itself be the default widget and which does not handle the RETURN key. Passing BUTTON_INITIAL will make it the initial default. BUTTON_DEFAULT means that if the focus lands on this button, it will become the one to respond to RETURN key.

To programmatically set BUTTON_DEFAULT, use setButtonStyle(BUTTON_DEFAULT). Calling setDefault(TRUE) will MAKE the button the default; this is different from ALLOWING it to be the default, which is what BUTTON_DEFAULT does.

Recommendations:

Only buttons normally terminating a dialog should have BUTTON_DEFAULT. For example, the "Accept" and "Cancel" buttons at the bottom of the dialog.
Only one single button should have BUTTON_INITIAL. This should correspond to the choice that would be the most often chosen one, e.g. "Accept". If the dialog does something dangerous, like "Erase All files" then make "Cancel" your default choice:- hitting RETURN is a reflex and in some cases its better for the easy path to lead to safety rather than to danger!
If you write custom widgets and your custom widget handles the RETURN key, your overload of setFocus() and killFocus() should call setDefault(TRUE) and setDefault(MAYBE), respectively.
Calling setDefault(TRUE) means the current default button will no longer be default one because your widget now deals with the RETURN key. Calling setDefault(MAYBE) when your widget looses the focus means the default button will revert to the initial default button (unless of course the focus lands on another widget which can handle the RETURN key!).

Shouldn't fx.h include fxkeys.h?

fxkeys.h

To make programs compile faster, the file fxkeys.h, which contains a very large number of definitions, is therefore not normally included.

I have this great idea, but you will need to rewrite all of the FOX library and applications.

No!

How do I monitor activity on sockets?

Another approach is to use the addInput() facility of FXApp. The addInput() call registers a callback message, and target object, to be invoked when the event on the file descriptor occurs. For example, adding:


        app->addInput(fd,INPUT_READ|INPUT_WRITE,myobject,MyClass::ID_FD);

On MS-Windows, instead of a POSIX file descriptor, you must use a handle. Thus, under MS-Windows, the addInput() API can be used to wait on a great variety of kernel objects, ranging from event objects (which is what you need to use for sockets), to process and thread handles, and so on. Please consult the MSDN documentation on Winsock2 for details.

What do the different version numbers for FOX mean?

major.minor.patch

odd

development

even

stable

The intent is for even-numbered releases to keep the header files untouched, to guarantee DLL or shared library compatibility. If bugs are fixed, the patch number will be increased. Thus, applications should be able to link to shared library versions of FOX with confidence. For odd-numbered releases, everything may be changed from one patch level to the next, so one would have to recompile applications (that's the nature of it being a development version!).

Why didn't you fix the problem of the last pixel of a line not being drawn on MS-Windows?

You may draw thicker lines; adding a pixel with thin lines (1 pixel wide) is possible, but with thick lines it gets kind of complicated.

You may be drawing with stipple style. The stipple algorithm is closely tied to the DDA and to draw the end-point properly you must know the state of stippling algorithm in order to decide what color to give the final pixel.

Drawing with patterns and various BLIT modes. There are ways to draw with hatched brushes, and you can use many different BLIT modes to combine foreground, background, and hatch patterns with the background. So it gets even more complicated....

Even if you can solve the problem of doing all the above, there is one problem left which you CAN NOT SOLVE. You can not solve it because of the mathematics of rational numbers:
```
   Y

   5
   4            oo@
   3         ooo
   2      ooo
   1   ooo
   0ooo
    0123456789012345  X
```
Suppose you draw the line above, but you want to include @. You'd think its a matter of specifying a slightly different end point P, such that @ is touched in the DDA algorithm.
However, this is impossible, because the line shown has a slope of 3:1, and this hypothetical endpoint would be at at (15,4 1/3) and of course that's not an integer coordinate. The next best thing would be either (15,4) or (15,5), but that will give you a different slope line (and totally different pixelization) altogether. In effect, rather than having a tiny problem at the end of a line segment, you now have many problems along the entire line.

The moral of the story is that we're basically better off NOT trying to fix this problem, but simply organize code so as to (a) minimize the reliance on line drawing, and use rectangle fills instead, and (b) whenever we do need to draw lines, try to make sure this effect is hidden, and finally (c) if all else fails, there is #ifdef style conditional compilation.

As it happens, I have been able to make do with (a) and (b) in almost all cases, and had to resort to (c) only once or twice.

Why doesn't FOX use ASSERTs to check API arguments?

As a library, FOX is installed and used by many programs, and so under normal circumstances it is compiled with optimization flags, and so assertions and such are normally removed.

Application developers may compile their own code with debugging enabled, but usually link against a pre-installed copy of the library.

Thus, errors in arguments and such need to be checked by means other than assertions.

If you're working on additional FOX widgets, or perhaps suspect a bug in the FOX library, then the library can be compiled for debug mode. In this case, we're interested to uncover bugs and inconsistencies in the library itself, so assertions and tracing and so on must be turned on.

The assertions in the library itself should however NEVER be triggered, even if the application program is ill-behaved or the library is used in the wrong way:- because the assertions are there to verify the correctness of the library itself, and the standpoint is that other checks should catch bad parameters to API's and other abuses.

Why can I not paste clipboard data out of a deleted window?

A cut or copy operation can be nearly instantaneous, even for very large data, as no actual data are being transferred.
It is more open-ended in terms of clipboard data types, since not all data formats need to be generated up front.
It allows for some optimizations; for example, if the requestor and the source are in fact the same application, no inter-process communication needs to be performed at all; data can be exchanged directly in memory.

The alternative would be to generate all clipboard-types up front; imagine what this would mean if we had 10 image formats and you clipped an image to the clipboard:- you'd have to place the same image on the clipboard in all 10 image formats just on the off-chance that one of them may be requested!

The source of the clipboard data is the widget from which the data was clipped to the clipboard; that widget is the one which owns the clipboard, and that widget is the one that will be asked to generate a specific representation of the data for a specific clipboard type when it is asked by another application. Only that particular widget has the methods and knowledge for generating the requested representation of the clipped data.

While this allows for a lot of flexibility in the clipboard data types, it does have a downside:- when the owner of the clipboard is deleted, so does the clipped data.

What is valgrind?

Valgrind

Use of uninitialised memory;
Reading/writing memory after it has been freed;
Reading/writing off the end of malloc'd blocks;
Reading/writing inappropriate areas on the stack;
Memory leaks -- where pointers to malloc'd blocks are lost forever;
Passing of uninitialised and/or unaddressible memory to system calls;
Mismatched use of malloc/new/new [] vs free/delete/delete [];
Some misuses of the POSIX pthreads API.

Purify

BoundsChecked

Valgrind translates x86 instructions into instrumented code, basically inserting various checks on memory references. Because its still not completely aware of all sorts of x86 instruction set extensions like 3DNow and SSE, you should probably compile your code in "vanilla" pentium mode.

If your code links against OpenGL libraries from NVidia then you can disable the OpenGL library's use of 3DNow and SSE by setting:

  export __GL_FORCE_GENERIC_CPU=1

If you care about software quality, you owe it to yourself to try valgrind out as it can catch a great many bugs; some memory bugs are like "time-bombs" and may linger in the code for a long time; valgrind can ferret them out.

When is a member function virtual or not?

Functions which need to be virtual are. Examples of these are functions like getDefaultWidth() and layout().
Certain functions which may be overloaded in derived classes are; for instance expandTree() is virtual because it allows a derived class to know when a subtree is unfolded.
Message handlers are never virtual. You can just add the same message handler in the derived class's message map, which is faster anyway.
Functions which should not be overloaded (e.g because it could break the abstraction, like for example getNext() and getPrev()), are never virtual either.
Other than the above 4 rules, non-virtual may have been chosen without good reason. On such cases, I'm open to suggestions.

Obviously the full scope of widget subclassing is not really known until people try; because of rule (4) chosing non-virtual is a better way to enforce the integrity of the abstraction.

Why does a toplevel window have different decorations than I specified?

hints

There are many Window Managers under X11, such as KDE, WindowMaker, FVWM, Motif Window Manager (MWM), and so on. The ICCCM document details a few common conventions that Window Managers are supposed to adhere to; unfortunately, decoration styles are not part of this document. Because of its historic popularity, many Window Managers have opted to follow the Motif Window Manager hints.

There is also some effort under way to define some more modern standards, the Free Desktop Organization. FOX adheres to many of the Free Desktop's standards, insofar as it does not conflict with Motif Window Manager standards (since FOX needs to work reliably under Motif for some time to come).

Under MS-Windows, the part that is responsible for the title and border drawing is implemented in the Windows DLL's that FOX needs to link to. The non-client drawing is handled by these libraries, ensuring that FOX's toplevel windows look and behave according to the particular version of Windows your FOX program runs on.

Since the behaviour of the decoration hints depends on the underlying system, FOX programmers must perform some testing under various systems to ensure that the particular combinations of hints they have chosen work as expected; the FOX library itself uses very conservative settings which are known to work properly on most Window Managers.

Why do none of the FXScrollArea derived widgets have a frame?

The longer and more accurate answer is a bit more complicated. The FXScrollArea widget, and its derivatives, present a small view of a larger content. The content may be a drawing, but sometimes also other widgets are involved, for example in the case of FXIconList. It is necessary to clip all drawing to the visible viewport of the FXScrollArea. This is made possible by making sure the FXScrollArea's scroll bars and scroll corners are always the topmost three children, and positioned so as to leave a simple rectangular viewport area in which the content is shown.

If FXScrollArea would draw borders or padding around itself, this would necessarily not be covered by the scroll bars and scroll corner; however that would present a problem as any content or sub-windows of the content would be drawn on top of the FXScrollArea's borders.

Thus, FXScrollArea does not support borders. If you need a sunken border around a scrolling widget, simply create a FXVerticalFrame with no padding as the immediate parent.

What is the Legal Status of FOX since your departure from CFD Research?

The arrangement is as follows:

CFD Research disclaims all Copyright Interests to the FOX Library.
CFD Research will continue to be able to use the FOX Library under the Lesser GPL license.

What is all this stuff with FXSelector and so on?

From which widget did the target receive the message? This is determined by FXObject *sender argument of the message handler.

What happened? The answer to this question is in the type-part of the FXSelector sel argument of the message handler. You can obtain the message type by means of the macro: FXSELTYPE(sel).

The identity of the widget from which the message was received. This is answered by the id-part of the FXSelector sel argument of the message handler. You can obtain the message id by means of the macro: FXSELID(sel).

Any other pertinent data. This data depends on the type of widget, the message type which was received, and is found in the void* ptr argument of the message handler. You must typically cast this to the appropriate type.

FXSEL(type,id)

For historical reasons, the data type used for the message-id, message-type, as well as the combined selector is FXSelector.

How do I add an icon for Windows Explorer?

  0 ICON DISCARDABLE "myapp16.ico"
  1 ICON DISCARDABLE "myapp32.ico"

Where, obviously, myapp16.ico and myapp32.ico are the icons you want to be associated with your application.

You will also need to convince your resource compiler to compile that, of course.

The TextField stops updating while the cursor is in it?

You've moved the focus to another Control, or
You've hit RETURN in the Text Field to accept the typed input.

Building and using DLL's with FOX under Windows.

FXAPI

FXEXPORT

__declspec(dllexport)

own

uses

FXIMPORT

__declspec(dllimport)

There are two layers of macros so for your own DLL and EXE building you won't have to remember what to do for export or import, you can use the FXEXPORT and FXIMPORT macros. Now, you can NOT use FXAPI. When you build your own library, that library is a importer of the FOX API but an exporter of its own API!

For example, in FXChart new symbol FXCHARTAPI is defined so that when it is compiled it could be import symbols from FOX yet at the same time export its own symbols.

So in a nutshell:

Compile FOX with -DFOXDLL and -DFOXDLL_EXPORTS.

Compile programs which use FOX with -DFOXDLL and nothing else.

Compile your own DLL's which use FOX with -DFOXDLL and -DYOURDLL_EXPORTS [see FXChart for example]. Your own FOX-based DLL's export ONLY their own symbols but import the core library's symbols.

Creating an MDI application.

So, GUI controls basically have FXMDIClient as their target. The FXMDIClient is a kind of delegator, in the sense that when it does not understand a message, it forwards it to its currently active FXMDIChild; if there is no such child, then control is returned to the calling widget with the "unhandled" message return code.

The FXMDIChild similarly does a delegation. It tries the content window first, then its target "document" object.

Since we do not know which FXMDIChild is going to be active, it is important to ensure that all message ID's are unique if you have different types of FXMDIChild widgets.

For example, an application may have a 3D viewer in one FXMDIChild and a text view in another FXMDIChild. We don't want messages intended for a 3D viewer to be connected to a wrong handler when the text view FXMDIChild is active.

So, I recommend a common base class for your various FXMDIChild subclasses, and to define all message ID's in there. Then various subclasses of this base class map whatever ID's they need to specific handlers.

If you also have a Document class as target of the FXMDIChild windows, then number the messages the Document deals with starting from the ID_LAST of the FXMDIChild base class widget in your application. See below:

  // MDI Child base class
  class MyMDIChildBase : public FXMDIChild {
  ...
  enum {
    ID_FIRST=3000,      // High number away from any ID's defined in widgets
    ...
    messages defined for all subclasses of MyMDIChildBase
    ...
    ID_LAST
    };
  ...
  };


  // Custom document class
  class MyDocument : public FXObjecvt {
  ...
  enum {
    ID_FIRST=MyMDIChildBase::ID_LAST,
    ...
    ID_LAST
    };
  ...
  };

This is convenient. For example, a "Cut Selection" message could have radically different implementations in the various subclasses, yet be invoked from the same single menu.

When a particular FXMDIChild is active, some message ID's will be mapped to a handler, and some will not be.

FOX can take advantage of this fact by allowing you to specify the AUTOGRAY or AUTOHIDE flags on certain controls. For example, if you were to specify BUTTON_AUTOGRAY on a toolbar button, the button is automatically grayed out when no corresponding handler is found in the currently active FXMDIChild, or when there is no open document at all.

BUTTON_AUTOHIDE works similarly, except that in this case the button will be hidden instead of simply grayed out.

When you use BUTTON_AUTOGRAY, it is of course going to be necessary to implement the SEL_UPDATE handler as well as the usual SEL_COMMAND handler, so that you can enable the button. You can enable the button by means of a message, so that your handler won't have to know what kind of widget the sender was.

Example:

  // Undo last command
  long MyDocument::onCmdUndo(FXObject*,FXSelector,void*){
    /// perform the command for undo
    return 1;
    }


  // Sensitize undo widget; the ID_ENABLE message
  // enables the sender [presumably a widget of some sort]
  // We don't need to know what kind of widget the sender is,
  // so we can actually use this handler for sensitizing toolbar
  // buttons as well as the corresponding pulldown menu commands.
  long MyDocument::onUpdUndo(FXObject* sender,FXSelector,void*){
    sender->handle(this,FXSEL(SEL_COMMAND,FXWindow::ID_ENABLE),NULL);
    return 1;
    }

  // Example: pulldown menu command
  new FXMenuCommand(editmenu,"&Undo",undoicon,clientarea,MyDocument::ID_UNDO,MENU_AUTOGRAY);

  // Example: toolbar command
  new FXButton(maintoolbar,"\tUndo",undoicon,clientarea,MyDocument::ID_UNDO,BUTTON_AUTOGRAY|BUTTON_TOOLBAR|FRAME_RAISED);

Of course there may be a few cases where you may need to perform a wholesale update of the user interface when the user switches FXMDIChild windows or documents. Some major widgets with lots of content should probably not be updated using the SEL_UPDATE mechanism.

There are two ways; first is the SEL_CHANGED from FXMDIClient; a better way, and the recommended one, is to catch the SEL_SELECTED and SEL_DESELECTED messages from FXMDIChild:

  // Switched to new active document
  long MyDocument::onChildActivate(FXObject*,FXSelector,void* ptr){
    if(!ptr || ((FXMDIChild*)ptr)->getTarget()!=this) activateDocument();
    return 1;
    }


  // Switched from old active documents
  long MyDocument::onChildDeactivate(FXObject*,FXSelector,void* ptr){
    if(!ptr || ((FXMDIChild*)ptr)->getTarget()!=this) deactivateDocument();
    return 1;
    }

The void* in these messages reflects the OLD FXMDIChild window that was active before the switch. The code above takes care of the case where there are multiple FXMDIChild windows which may have a common document, and we would of course only want to update the GUI controls when we switch documents, not when we switch between FXMDIChild windows of the same document.

The implementation of activateDocument() will be responsible for setting up the GUI controls with data pertaining to the document. Likewise, deactivateDocument() should tear down the user interface and leave widgets in their pristine state [as if there were no document].

MS-Windows GDI handle limits.

These limits manifest themselves when calls to create() are failing by throwing an exception.
Windows NT, 2K, and XP probably have higher limits than Windows 95, Windows 98, and Windows ME.

It is therefore important to make sure that resources are deleted as soon as they're no longer needed. Since its pretty fast to create resources, its best to delay creation of windows and icons until they're actually needed.

In particular, dialogs should "own" their icons, and delete them in the dialog's destructor. Try to construct dialogs only when they're actually brought on-screen, and try to delete them when the interaction with them is done.

Note that un-created() icons and images do not use any handles in the system, so refrain from calling create() on icons or images if all you want to do is load and manipulate the image's pixel data. You only need to call create() when images are to be drawn into or used as sources for drawing (like e.g. drawing onto widgets).

How to I make a back-buffered widget?

Note that there are two types of drawing: program-initiated, and paint-message initiated. In a paint-message initiated onPaint(), you simply do:
```
FXDCWindow dc(this,(FXEvent*)ptr);
dc.drawImage(backbufferimage,0,0);
```
and you are done; the backbufferimage will never get clobbered so there's no need to regenerate it each time you paint. Passing the FXEvent to FXDCWindow constructor sets the clip rectangle to the dirty-area, and this means that in most cases, you'd only paint the smallest sliver of the backbufferimage. In other words, this is pretty FAST and totally independent of the complexity of the drawing in the image!
When your widget changes size, layout() is called. You will need to overload layout() and resize the image. The layout() function is also called when there is reason to believe stuff is "dirty". The layout() function you implement needs to treat two cases:
- If it changed size, resize the image. Code will be more or less like:
```
if(backbufferimage->getWidth()!=width || backbufferimage->getHeight()!=height){
  backbufferimage->resize(width,height);
  }
```
  The test is obviously needed because resizing an image is slow and painful: we really don't want to do it unless its necessary!
- If the image changed size, or if it was dirty, redraw the image in the layout() function. This goes something like this:
```
FXDCWindow dc(backbufferimage);
dc.drawLine(..); ... // or whatever drawing commands you need!
```
  At the end of layout() you set the dirty flag back to false:
```
flags&=~FLAG_DIRTY;
```
Whenever you programmatically change the contents to be displayed in the backbufferimage, call recalc(). This sets the FLAG_DIRTY and thus instigates a layout() at some point in the future.
Note it doesn't redraw immediately; it just sets a flag to do it later, when we return to the event loop. Thus, you can change many things about the widget, and yet incur the cost of redrawing only once!
Some examples of this in FOX widget collection: FXGradientBar, FXColorWheel, FXChart, and a few others. In the case of FXColorWheel, the backbufferimage is actually constructed pixel by pixel, and the whole off-screen image regenerated by a call to backbufferimage->render().

It should be clear that the logic above takes great pains to avoid the hard work [redrawing the off-screen image] as much as possible. 99% of the time, we can redraw some tiny sliver from the backbufferimage using a fast BLIT operation. Then for the remaining 1% of the time, we'd regenerate the contents only.
Only once in a while we have to both resize and regenerate the contents; but at least, we've put this work off till idle time! Because at idle time, the only thing we'd be doing otherwise would be to wait for events anyway!

Advanced drag and drop topics.

When the widget is the drag source, it calls beginDrag(), handleDrag() and endDrag() in succession.

When you do a drag and drop, two programs are normally involved [although drag and drop also works within the same program]. When the drag source [sender] performs a drop using endDrag(), a drop-message is sent to the drop-target [receiver]. After sending this drop-message, the sender goes into a little event loop, waiting for confirmation that the drop-target has obtained the data, and coordinating with the receiver to transfer the drop-data.

After the data transfer has completed, the receiver sends a finish-message to the sender to let the sender know it has obtained the data; this message is normally send automatically upon returning from the drop-message handler. When the sender receives this message, it can then wrap up the drag operation, and return from the endDrag() routine.

As the sender is waiting for the finish-message in its event loop, it keeps timers to ward against receivers crashing or just being broken in some way. After all, we don't want a bad behaviour in another program to cause a problem in the sender itself. We assume that if a timeout has occurred, the data transfer has been unsuccessful and thus the sender should not delete any data in that case.

Now, in most simple drag and drop cases, the operations performed by the receiver after obtaining the data from a drop are pretty quick, and no special handling is needed. However, when a receiver needs to do a lot of work upon receiving a drop-message, the receiver can explicitly send a finish-message to the sender [dropFinished()] after obtaining the data. We thus release the sender from its event loop quickly, before the receiver would normally return from the drop-message handler. Having thus released the sender, the receiver can then proceed to work on the data at its leisure.

However, a problem still exists when sender and receiver are one and the same. Because in that case, control cannot return from endDrag() because the drop-message is still being processed. To avoid these problems, we need to ensure that control returns to the main event loop before the drop-data is processed.

The solution to this problem is to set a chore to process the actual data, and return from the SEL_DND_DROP handler immediately. This way, if sender and receiver happen to be the same, we are assured that the chore handler is executed after returning to the top-most event loop.

Now, the sender can return from the endDrag() function, and normal event processing resumes. The first thing that will happen after this is the chore which we've set in the drop-message handler. Since we're no longer in endDrag()'s modal loop we can invoke anything we want in the chore handler, which includes popping dialogs and invoking popup menus!

FOX Exception handling.

We want to ensure that when exceptions are thrown, the widget can recover. To this end we notice that BEFORE the message handler was invoked, things were still OK. Therefore, the point of message handler invocation represents a safe roll-back point.

To ensure that a widget can be brought back into a known state, message handlers are invoked through the tryHandle() function. Any exceptions that are raised while executing the handler can be caught in tryHandle().

However, not all exceptions should be treated this gently; after all, in correct programs, only resource-exceptions are to be expected, whereas other types of exceptions may be raised only in the presence of non-recoverable errors or incorrectly functioning software.

These kinds of exceptions should be passed on, to allow developers to debug their software.

In FOX, FXResourceException is the type of exception that is expected to be recoverable. It includes typical scenarios such as running out of disk space, RAM memory, or window-handles. It is important to distingish these errors from programming errors:- perfectly correct programs can, after all, run into resource limits on the user's machine, which has only finite amounts of memory, disk space, and other resource. Conversely, programming errors such as indexing lists out of range, and so on, should not occur in well-written software.

Consider the following code-fragment:

// About box
long TextWindow::onCmdAbout(FXObject*,FXSelector,void*){
  FXDialogBox about(this,tr("About Adie"),DECOR_TITLE|DECOR_BORDER,0,0,0,0, 0,0,0,0, 0,0);
  FXGIFIcon picture(getApp(),adie_gif);
  ///// build a gui //////
  about.execute(PLACEMENT_OWNER);
  return 1;
  }

Note that other exceptions than FXResourceExceptions are not caught in tryHandle().

Thus, to recap:

FXResourceException's are thrown by FOX, and caught in FOX, but may unroll through the application-programmer's own message handler-code. You can use them in your own code, but keep in mind that they're intented for recoverable types of errors, and not for detecting programming errors.
You can throw other kinds of exceptions [exceptions not related to FXException], but FOX will not catch them. However, since these will unroll through tryHandle() and the widget's event processing code, there will be a possibility that the widget will remain in an inconsistent state. Its therefore probably better to avoid raising these types of exceptions unless they're caught prior to returning from the message handler.
Writing your message-handlers exception-safe allows your program to fully recover from resource errors, should they occur.