Frequently Asked Questions |
Questions.
Why does FOX look so much like Windows?
Has FOX been ported to the Apple Macintosh?
Which Systems are supported by FOX?
Why do I get an `illegal icon specified' message when I change some Widget's icon?
Compiling FOX as a DLL under VC++ gives me a unresolved external symbol?
When do I call flush(), forceRefresh(), refresh() and update() after a change?
When I construct a window at the beginning it works but when I construct it later it doesn't
The FOX web-site is now GIF-Free!
DialogBox with its own MenuBar dumps core.
How does FXStream serialize an FXObject?
Answers.
Why does FOX look so much like Windows?
FOX looks much like Windows in part because of historical reasons, and
in part because it is intentional. Having FOX look similar to Windows
means the users of a FOX application will be able to bring to bear their
prior experience on Windows, and therefore they will be able to be productive
much quicker.
But let there be no mistake about it:- for software developers, FOX
looks very differently internally.
Has FOX been ported to the Apple Macintosh?
FOX is written to be very portable; it basically relies only on core system
facilities such as drawing primitives, mouse/keyboard event inputs, and some
operating system facilities.
This means that at least in principle, FOX could be ported to other systems such
as the Apple Macintosh.
Currently, however, no Mac port exists. The author has no access to a Mac, and
there does not seem to be an overwhelming demand for a Mac port either.
Which Systems are supported by FOX?
There are two main ports of FOX:- UNIX/X11 and MS-Windows. Specifically, FOX is known to work on the following systems:
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.
Why do I get an `illegal icon specified' message when I change some Widget's icon?
Basically, an Icon [Widget, Image, Font, etc] comprises a part which lives in your program [the client-side], and a part which lives in the X-Server or GDI subsystem [the server-side].
The C++ CTOR 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:
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?
If you build a project under VC++ to compile a FOX application, do not forget to specify -DFOXDLL on the compiler command line. Without it, you will get an error like: error LNK2001: unresolved external symbol "public: static struct FXMetaClass const FXApp::metaClass" (?metaClass@FXApp@@2UFXMetaClass@@B). Or words to that effect.
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?
Under normal circumstances, the display on the screen is kept up-to-date automatically. However, FOX uses a lazy screen refreshing technique. The lazy technique allows your callback routine to make lots of changes in the GUI, then update the screen in one fell swoop. This obviates the need that some other toolkits have for freeze/thaw API's.
There are several aspects to this: repainting the screen, i.e. processing expose or repaint events, performing layout computations, and performing GUI updating.
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:
When I construct a window at the beginning it works but when I construct it later it doesn't
When you construct a window before calling FXpp::create(), the window will be created when all windows are created. If however you construct a window later on, then you need to call window->create() yourself.
Please refer to the section about creating icons for a more detailed explanation.
When deriving classes from FOX Widgets such as FXDialogBox, make sure you're messages are numbered so as to not conflict with those of the base classes. The most simple way is to continue numbering from where the base class left of; I suggest the following C++ trick:
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.
The FOX web-site is now GIF-Free!
The FOX web site is now GIF-Free! Please take a look at the Burn All Gifs site to see why we've done this.
FOX does not contain any GIF compression, only decompression; 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. Typically, GIF icons are about half the size of BMP icons.
For more, see The Case Against Software Patents.
DialogBox with its own MenuBar dumps core.
When invoking a command, my application displays a DialogBox which has its own MenuBar. Then the DialogBox runs modally for a while, and upon completion it is deleted. Some time after that the application core dumps; what gives?
The answer to the problem is that MenuPane is a self contained widget which
is not owned by the MenuTitle or MenuCascade; this way, the MenuPane may
be reused for example as a right-mouse popup menu.
However, as the DialogBox is deleted, some of the MenuCommands still refer to it.
Typically, it is caught during GUI update:- when MenuCommand is being updated,
it will try to send a SEL_UPDATE to the demised DialogBox, and will print out a
message such as ``MenuCommand::onUpdate: references a deleted target object at
0001bcfed''.
In a few cases, some other message is sent to the target first, and the application
will core dump because the target object is no longer valid.
Solution: the destructor of your DialogBox should explicitly delete
the MenuPane's constructed in the DialogBox.
In fact, the DialogBox's destructor should probably destroy all resources previously allocated
in the DialogBox's constructor, such as icons, images, bitmaps, and so on.
Although it is safe to do so, there is no need to delete any Widgets, however.
How does FXStream serialize an FXObject?
When you serialize a pointer to an object, like for example:
// Declarations FXStream stream; FXDocument *document; // Serialize stream.open(FXStreamSave); stream << document; stream.close(); // Deserialize stream.open(FXStreamLoad); stream >> document; stream.close();What really happens when you serialize a pointer to an object is the following:
When you deserialize an object is:
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.