X windows, wxWindows. Each platform has its own way of returning
a variable length string, and its own rules about how you're supposed
to dispose of the string. Now all platforms do the same thing: they
allocate a Bit8u buffer with C++ "new" and copy the clipboard data in,
then release the clipboard data in the platform-specific correct way.
The Bit8u buffer is sent to the keyboard code, which frees it with
delete [] when finished.
- modified: gui/wxmain.cc gui/wxmain.h
X windows, wxWindows. Each platform has its own way of returning
a variable length string, and its own rules about how you're supposed
to dispose of the string. Now all platforms do the same thing: they
allocate a Bit8u buffer with C++ "new" and copy the clipboard data in,
then release the clipboard data in the platform-specific correct way.
The Bit8u buffer is sent to the keyboard code, which frees it with
delete [] when finished.
- modified: gui/wx.cc gui/x.cc gui/win32.cc iodev/keyboard.cc
files that need them. This is more in line with the other gui libraries,
and the compile line is easier to read.
- modified: Makefile.in configure.in configure gui/Makefile.in
delivered to both the GUI and simulator thread, so they both call
bx_signal_handler. This can lead to deadlock as multiple threads enter
BX_PANIC and try to show a dialog box at once. To solve the problem, I made
a function isSimThread() which can be called from anywhere. If the
bx_signal_handler is called from any thread OTHER THAN the simulation thread,
it returns without doing anything. As a result, only one thread is allowed
to enter the signal handler code, and now control-C works correctly.
Bochs to immediately read the bochsrc and start simulating immediately (as
opposed to going into the configuration interface first). Now -q does
the right thing in the wxWindows interface. It behaves as if you selected
Read Configuration and then Simulate:Start.
- modified: main.cc gui/siminterface.cc gui/siminterface.h gui/wxmain.cc
wxHAS_RAW_KEY_CODES is not available in the wxWindows library.
my patch "patch.wx-raw-keycodes" adds wxHAS_RAW_KEY_CODES to the wxWindows
library, and it will also be in wxWindows 2.3.3 and beyond.
correct name for floppy and cdrom devices:on windows, A:, B:, etc;
on Linux /dev/fd0 and /dev/cdrom.
- It's perfectly ok to type device names into the blank on those dialog
boxes, but the label "Disk Image File:" sort of implies that it has to
be a file. To try to avoid confusion change the label to simply
"Disk Image:".
on win32. I believe this is the same problem that scarlip referred to as
"it doesn't start reliably. sometimes it works, sometimes it won't".
See comments in gui/wx.cc (dimension_update) for details.
- since dimension_update is called from the simulator thread, it needs to
get the GUI mutex before calling any wxWindows functions. Now it does.
- add lots of IFDBG_VGA(...) lines which I use to diagnose various problems.
They are compiled away by default (for performance). See definition of
IFDBG_VGA() in gui/wxmain.h.
values. All wxWindows dialogs return wxID_OK or wxID_CANCEL. The
wxOK and wxCANCEL symbols are ONLY used in input arguments that determine
whether to display the ok and cancel buttons. Now I'm doing the same.
Return values are wxID_OK if they pressed the ok button, and wxID_CANCEL
if they pressed cancel.
SetToolBitmapSize() to set the icon size to 16x16; when I changed the icon
size I forgot to change SetToolBitmapSize() and somehow it looked ok on
wxGTK.
- change mouse tooltip to "(Mouse Not Implemented Yet!)" for now
has a 16bit signed value. If you try to set the max above 32767, it
overflows and does stupid things. To combat this tendency, I now use
the SPINCTRL_FIX_MAX(x) macro when setting the max range of a spinctrl.
On platforms that need it, this will saturate the range at 32767.
- implement the Edit Keyboard dialog using ParamDialog instead of the
handcoded thing.
- make Serial/Parallel dialog look a little better
- change order of "other" dialog to get ips and vga_update_interval on top
ParamDialog. When a boolean param changes, I read its dependent_list
field to see which other parameters depend on it. Then, for any
dependents that are actually showing in the dialog, I set their
enable bit accordingly. This required addition of another hash table,
called paramHash. The two EnableChanged() methods implement this.
- remove all ConfigKeyboardDialog code because I can do just as well
using the generic ParamDialog.
- fix bug that caused occasional crashes. To attempt to find all the
choices in an a wxChoice control, I was calling GetClientData() on
increasing index until it returned NULL. The docs implied that this
was safe, but it's not. Eventually I found an apparantly undocumented
call wxChoice::GetCount() that gives the number of strings in the
choice box and it allows me to do the right thing.
to change the enable/disable status of other parameters worked fine for
the text mode interface but poorly for the wxWindows gui. So I
implemented it a different way. Now in every boolean parameter, there is
a field called dependent_list which is a list of parameters which
are enabled/disabled by that boolean. Having this list available
allows both the text mode CI and the wxWindows CI to know which fields
should be enabled and disabled as a result of a boolean changing value.
- when the set() method of a bool param is called, or when the
dependent_list is changed, a private method called update_dependents()
changes the enabled status of all dependent parameters.
- add macros to get parameter ids of serial and parallel port parameters,
using the port number as an input variable.
to change the enable/disable status of other parameters worked fine for
the text mode interface but poorly for the wxWindows gui. So I
implemented it a different way. Now in every boolean parameter, there is
a field called dependent_list which is a list of parameters which
are enabled/disabled by that boolean. Having this list available
allows both the text mode CI and the wxWindows CI to know which fields
should be enabled and disabled as a result of a boolean changing value.
- when the set() method of a bool param is called, or when the
dependent_list is changed, a private method called update_dependents()
changes the enabled status of all dependent parameters.
a method to add the parameters (bx_param_c) that you want to edit,
and display it. It knows how to display and edit boolean, int,
enum, and string, so it can do a reasonable job on any parameter.
The end result is not as nice as a box that you lay out by hand, but
it's decent. The most obvious thing that's missing from
ParamDialog-generated dialogs is that I haven't found a way to
make an "Enable" button that enables/disables a bunch of other
parameters. I'll keep thinking about that.
- using ParamDialog, I made dialogs for Sound, Cmos, Serial/Parallel,
32bitOSloader, and an ugly catch-all category called other.
Now I believe you can edit every single option using wxWindows.
- remove the format string from GetTextCtrlInt() because the strtoul
conversion is better than the sscanf with a format string (it supports
both base 10 and 16 with 0xFF notation).
- modified files: gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h
- also other browse buttons were somewhat broken in that they didn't
set the initial value of the wxFileDialog. Now all text fields
with a browse button use a single function BrowseTextCtrl() to
avoid future problems of this sort.
- if the Ok on the MemoryConfigDialog is rejected because the integers
can't be parsed, now give a more specific error message that points you
to which field has the illegal value.
- print hex numbers with CAPS. With proportional font this is much
easier to read.
- accept either strings with base 10 or 16 numbers in GetTextCtrlInt by
default. If the sscanf fails, accept anything that strtoul can
read. Unfortunately legitimate "-1"'s being returned from strtoul will
be rejected, but at present there is no need for negative numbers in
textfields anywhere.
- modified files: gui/wxdialog.cc gui/wxdialog.h
and also the optional rom settings. I think it all works except that
the Browse buttons aren't hooked up yet.
- modified Files: gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h
die, or ask the user for each type of event. It has a button that
will lead to the "advanced" dialog, which doesn't exist yet.
- in gui/wxdialog.h, sketch a few more dialogs to be done soon
- modified: gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h
- for all modal dialogs that return a boolean result, return either
wxOK or wxCANCEL instead of 0,-1.
- you can view the NetConfigDialog box if you choose the Edit:Network menu
item, but it's not connected to the actual parameter values yet.
into normal C strings. After asking about it on wx-users, I understand
it better now.
Example of unsafe code:
char *filename = dlg.GetFilename().c_str ();
printf ("file name is %s\n", filename);
The problem is that dlg.GetFilename() returns a temporary wxString
that goes out of scope at the end of that line of code. The "filename"
string is unstable if you write it this way.
Example of safe code:
char filename[1024];
wxString fn (dlg.GetFilename ());
strncpy (filename, fn.c_str (), sizeof(filename));
printf ("file name is %s\n", name);
Now we have a stable copy of the wxString in "fn" which is usable
as long as fn is in scope.
- also now we use wxStrings (almost) all the time in the interface to the
wxdialogs. Any conversion from char* to wxString and back is done in
wxmain.cc now.
