Clarion Professional Developer 2.1 needs Ctrl-Break passed to the executing program in order to open the Clarion debugger.

[zydanielson]

I'm writing this up as a Feature Request. As I'm new to DOSBox-X, I really don't know if this is a bug or not. Perhaps a moderator can decide.

The Clarion Professional Developer 2.1 is a suite of exes that looks like this:

When you highlight "Editor" and press Enter, it runs cedt.exe. Esc is used to exit the editor, which returns you to the developer suite above. "Compiler" runs ccmp.exe, etc. The process of developing a Clarion 2.1 program is to use the Editor to create a source file with extension ".cla". Then you use the Compiler, which creates a compiled version with extension ".pro" - also called a processor file. Then you use the Processor (cpro.exe) to test and debug the program. Here is the main menu of my client's system, written in "master.cla" and compiled to "master.pro":

Running the Clarion 2.1 Processor inside VMware or Oracle VirtualBox, when I click Ctrl-Break, I get: The debug module has opened up on top the running "master.pro" allowing me to examine variables, trace, step through a line of code at a time, set breaks, etc. Also, as you can see above, the debugger says "Stopped for: Ctrl-Break". This indicates that both VMware and VirtualBox are sending a true Ctrl-Break to the Clarion processor module, opening the debugger.

An Explanation of a Menu Standard in Clarion Professional Developer 2.1 When a menu such as "master.pro" above is executing (in any DOS environment), pressing the first letter of a menu item is designed to move the highlight to that menu item. In the "master.pro" menu you'll notice there are two items beginning with "C". These are "Clients" and "Cloth". Pressing C on the keyboard moves the highlight selection back and forth between these two options. This works as desired using DOSBox-X.

The Problem When I run "master.pro" in cpro.exe inside DOSBox-X, pressing Ctrl-Break does not open the Clarion debug module as it does in other virtual DOS environments such as VMware and Oracle VirtualBox .

What I Suspect Might Be Happening I tried pressing Ctrl-C to see if that would produce the hoped-for Ctrl-Break behavior. But Ctrl-C seems to send a "c" to the Clarion Processor, causing the highlighted menu selection to move back and forth between "Clients" and "Cloth" just as before. This gives me the impression that DOSBox-X does not pass a true Ctrl-Break or Ctrl-C to the executing Clarion Processor.

The Desired Behavior I don't need Ctrl-C to work, but I do need Ctrl-Break to work so that the Clarion Processor will open the Clarion Debugger. There is a runtime environment (crun.exe) that runs the Clarion 2.1 programs without the overhead of the Clarion 2.1 debugger. In my testing so far, this works fine with DOSBox-X. But my client (to this day) asks for modifications and new additions to his Clarion 2.1 system. Without the capability of sending Ctrl-Break to the Clarion Processor (cpro.exe), I am unable to develop and test new programs, or to debug programs already written. If DOSBox-X was not designed to send a true Ctrl-Break to the program executing inside it, then this is a Feature Request. If it should be capable of doing this, I haven't found out how to accomplish it, meaning it might be a Bug.

VMware and Oracle VirtualBox work fine in both the runtime and the processer/debugger. My whole reason for turning to DOSBox-X was for speed. When running in those other virtual environments, we are running a virtual Windows 7 with XPMode inside that: a virtual within a virtual within a virtual. It is slow as molasses in January. I sure would love to be able to set aside that environment and develop and run Clarion 2.1 programs in DOSBox-X alone.

I look forward to hearing your comments and responses.

Thank you, Zy Danielson

[joncampbell123]

DOSBox-X does emulate CTRL+C and CTRL-BREAK in some fashion, though it's evidently not as comprehensive as needed here.

[Wengier]

@zydanielson Thanks for posting here! Yes, DOSBox-X does support Ctrl+C/Break handling in some fashion as @joncampbell123 said, primarily in the DOS shell and shell commands (DIR, MORE, SORT, etc), but Clarion Professional Developer 2.1 is apparently a full-screen application, whose Ctrl+Break requirement is apparently not supported yet. But I will certainly look at it and see if it can be supported as well.

[Wengier]

The main obstacle for me to check the Ctrl+Break key combination in DOSBox-X is apparently that my main computer (laptop) does not actually have a Break (or Pause) key, so I could not type the Ctrl+Break key combination directly here. Ctrl+C works well in DOSBox-X for the most cases, but I was never able to check for Ctrl+Break easily because of this reason. I did check it today on a different laptop, which can emulate the Ctrl+Break key by pressing Ctrl+Fn+Pause, and it turned out to not work very well in DOSBox-X. So I have to check why by testing it on this computer (instead of my main computer which lacks the Break key).

[zydanielson]

Thank you, @Wengier I will wail patiently. I appreciate your time and work.

[zydanielson]

@Wengier: I was having a problem with vDosPlus and wasn't sure what to do about it. My client asked me to get his system running in both DOSBox-X and vDosPlus, particularly since I've clocked some Clarion 2.1 programs that run 5-10 times faster under vDosPlus. Since vDosPlus is dormant at present, I decided to look into vDos itself to see if that might be a better solution. I posted on the vDos forum here and received a response from Jos within 7 hours. So that project is very much alive. I liked what he had to say so if you have time, perhaps you might look at that thread from my post down.

In case you're pressed for time, here are some excerpts from the vDos thread where I posted:

Me:

I have gotten his [my client Allen, Brecon Knitting Mill, Inc.] system running and mostly tested in the Clarion 2.1 runtime under vDosPlus (which is very fast) and DOSBox-X (which is 5 to 10 times slower). So we might be able to use either of those, and possible even vDos, as long as I don't use the Clarion 2.1 debugger in the emulator. I suppose, worst case scenario, I can continue to run Oracle VM VirtualBox running a virtual Windows 7 running it's virtual XPMode - a virtual within a virtual within a virtual, which is probably why it is so slow, using this setup to debug changes to his programs I'm still supporting as well as new programs my client is always asking me to develop in Clarion 2.1.

Jos from vDos:

With correct settings, DOSBox (don’t know about DOSBox-X) should be able to run faster than vDosPlus (https://www.youtube.com/watch?v=wSo7hYFHA7g).

I could eventually add a rather simple: Set the BIOS break flag when appropriate. Starting a DOS function, check if this flag is set. If so and Int 23 is hooked/replaced, start that routine. If it returns AL=0 end the DOS program, else continue with the DOS function (http://www.ctyme.com/intr/rb-4110.htm).

[Wengier]

@zydanielson Thanks for letting me aware of the discussion with Jos. And yes, there are efforts to improve the speed in DOSBox-X in the last a few days. There is now a dynamic_x86 core (core=dynamic or core=dynamic_x86) in the latest code which should make it faster. Also, be sure to set cycles=max as well. I checked with CCMP.EXE which should run notably faster with these settings applied than with the default setting. A 32-bit Windows binary for the current DOSBox-X code is available from:

Download link: dosbox-x-update.zip

And sure, the improved Ctrl+Break support is in the plan. Thanks for linking to Jos's comment.

[joncampbell123]

In order for CTRL+Break emulation to happen as expected, the current CTRL+Break handling needs to be moved to another mapper shortcut.

The current CTRL+Break handling pauses emulation and allows you to "single step" emulation frame by frame in cases where you need to carefully examine what the DOS game is doing on screen. It was initially chosen because Alt+Pause was carried over from SVN to break into the debugger.

[zydanielson]

@joncampbell123 Hi Jon. Not being a DOS gamer, I can only imagine and visualize what your reply fully means. But I am confident you and @Wengier are making the very best decisions for the DOSBox-X project. I look forward to see how this issue turns out.

@Wengier, next I will try the speed up options you posted above. I'll do some testing on the live Brecon system and get back to you.

[joncampbell123]

@zydanielson It means CTRL+Break is currently associated with a function that is useful but less important than emulating what CTRL+Break does on real hardware. It needs to signal an interrupt (like the BIOS does) so CTRL+Break works as expected when DOS programs hook it.

[zydanielson]

Thank you, @joncampbell123. This helps me see what the plan is for this issue.

@Wengier: All I can say is WOW. With the new update, core=dynamic_x86, and cycles=max as you advised, everything I have tested is running lightning fast in both the development and production runtime environments of Clarion 2.1! Allen will be very pleased and I believe we will now drop testing with vDosPlus and proceed from this point relying solely on DOSBox-X.

I am amazed and happy! Thank you for this great work!

[joncampbell123]

The BIOS CTRL+BREAK interrupt is INT 1Bh.

http://www.ctyme.com/intr/rb-2442.htm

[Wengier]

@zydanielson Glad to hear that!

@joncampbell123 I hope there is the Break key on your development computer, which will make handling the key much easier.

[joncampbell123]

@Wengier My dev laptop lacks separate arrow keys, but it does have a Pause key. On traditional AT keyboards, that key is usually labelled Pause/Break.

[Wengier]

@joncampbell123 Sure, I used desktop computers which had the Pause/Break key back when I used DOS as my primary OS in the 2000s. But now I am using Windows on laptops which may no longer have such keys.

[zydanielson]

It is probably good that you've run into this keyboard obstacle already, @Wengier.

Is it possible to create a setting that would enable mapping a chosen key combination to generate a Ctrl-Break that will return the necessary interrupt to the program running in DOXBox-X? In the future, if Pause/Break keys do disappear from popular keyboards, it would be a shame to make this change and discover because a user bought new hardware there was no Ctrl-Break or Ctrl-Pause they could press. I use a Logitech keyboard I just bought recently that still has the Pause/Break key. But who knows where hardware will go in the future? For DOSBox-X to attain (and retain) the status I believe you want it to hold, it should be "hardware/keyboard" independent, just as important as "cross-platform," etc. Having a setting that allows the user to map an existing key to Ctrl-Break, probably defaulting to OFF (since Jos said most end-user programs don't use Ctrl-Break, and he's probably right) would be a good solution that gives this issue support where it's needed, as in the case of Clarion 2.1 Developer (but there are probably others). This might solve the Ctrl-Break issue, while also ensuring keyboard independence.

[joncampbell123]

@zydanielson I will sit down tonight and get the INT 1Bh handler implemented, and the IRQ1 handler to call INT 1Bh if CTRL+BREAK is pressed. According to RBIL, MS-DOS hooks INT 1Bh to set the same flag it sets for CTRL+C. It looks like (through the debugger) that the MS-DOS 6.22 INT 1Bh handler sets a flag to 0x3 on INT 1Bh.

[joncampbell123]

I got CTRL+BREAK to work. The only thing left to work on is the mysterious issue where CTRL+BREAK also seems to toggle the cursor insert state as if INS was also pressed.

[joncampbell123]

Actually it turns out that issue was caused by a missing break statement between the CTRL+BREAK/SCROLL and NUMPAD INSERT cases.

[joncampbell123]

Now looking at Neko Project II source code to see if some equivalent exists for PC-98 and... apparently they use INT 6h as the vector called by the BIOS for the STOP key (PC-98 equivalent of CTRL+BREAK).

Apparently INT 5h is for the COPY key.

Did anyone over there think to change that once Intel defined INT 6h as the Invalid Opcode exception? 🙃

[zydanielson]

My only question is if the Ctrl+Break you got to work will activate the Clarion debugger in the processor module. If so, I can live with having to toggle other key(s) back to their original state after it is pressed (if I have to).

::: chuckle :::

[joncampbell123]

@zydanielson CTRL+BREAK emulation seems to work properly with every DOS program that takes input on STDIN, and I'm able to break out of a QBASIC program with it, so it should work now.

[Wengier]

@joncampbell123 Thanks for the new handler. Yes, I can confirm it indeed works in QBASIC on the latop that has the Break key, which is great. However, at this time it does not yet seem to work either from the the integrated DOS shell or from Clarion, unfortunately. For example, from the DOS shell pressing Ctrl+Break has no effect (but Ctrl+C does). And from Clarion compiler pressing Ctrl+Break still cannot activate the debugger yet. I have uploaded a zipped Clarion package that you can use it for testing:

Clarion download link: clarion.zip

Extract the files and run cpro options. Press Enter and you will see the main menu. Pressing Ctrl+Break is supposed to activate the debugger here, but it does not seem to work yet. Could you please check it out? Thanks!

[joncampbell123]

@Wengier I must have fixed it since the last announcement. Debugger works here.

[Wengier]

@joncampbell123 I have checked out the latest code, but for some reason there seems to be no change on the laptop I tried, so I will simply assume the Break key on this computer is partly faulty.

@zydanielson I have uploaded the updated Windows binary based on the latest code. Please check it out:

Download link: dosbox-x-update.zip

[joncampbell123]

@Wengier Are you holding CTRL while pressing Pause/Break?

On real hardware, Pause/Break by itself is treated as a command to pause execution (it just loops in the ISR until you hit a key or pause again).

[rderooy]

Perhaps a onscreen-keyboard option would be a good idea? There is SDL_ShowScreenKeyboard() but that seems to be just for showing the Android/IOS keyboard. It may work on Gnome, since that also supports a onscreen-keyboard with touchscreens, but it will not have the right layout with special keys like the Break key.

The problem is that if you implement it yourself, you would need tons of possible keyboard layouts.

[Wengier]

@joncampbell123 On this laptop I have to press Ctrl+Fn+Pause to emulate Ctrl+Break as on a desktop computer. So I am not sure if this can cause issues with the handler. But I did hold both Ctrl and Fn keys while pressing the Pause key.

@rderooy I hope the Windows' built-in on-screen keyboard could work in such cases, but unfortunately it does not (it does not send keys to the DOSBox-X window). It is certainly a plus to have a on-screen keyboard built into DOSBox-X, but implementing it will apparently require some work as you said.

[rderooy]

There are various alternative key combinations depending on the laptop vendor that may trigger Break or Pause. https://en.wikipedia.org/wiki/Break_key#Keyboards_without_Break_key

On my ThinkPad pressing Fn-B or Fn-P seems to work.

edit I can confirm that the clarion debugger works with either Fn-B or Fn-Ctrl-B. And I can also trigger SysRq with Fn-S and ScrLk with Fn-K

[Wengier]

@rderooy Great to hear that it works! Does Ctrl+Break works in your DOSBox-X's DOS prompt too?

@zydanielson You certainly want to check out the updated DOSBox-X build above and see how it works.

[Wengier]

@rderooy Meanwhile, I will check out if there is any key combination that can trigger the Break key on my development computer.

[rderooy]

@rderooy Great to hear that it works! Does Ctrl+Break works in your DOSBox-X's DOS prompt too?

You mean the integrated DOS? When I press Fn-B or Fn-Ctrl-B at the DOS prompt, I get the same as Ctrl-C. And when I start Clarion and press the key combo, the debugger starts just like in the screenshot from @joncampbell123

[Wengier]

@rderooy I see. So there must be something wrong with the Pause key on the laptop I tried.

[zydanielson]

Sounds like a lot of progress has been made. Thanks everyone. However, I downloaded the update @Wengier posted and I cannot bring up the Clarion debugger in cpro.exe with my current Logitech keyboard. I have tried Ctrl-Break and Shift-Ctrl-Break since the key is labeled Pause/Break.

I have an older Logitech keyboard that has an Fn key. On that keyboard there is a gold colored (indicating Fn) "Pause/Break" label on top of the "End" key. I have tried Fn-Pause, Fn-Break, Fn-P, Fn-B, and all those in conjunction with Ctrl, Shift, and Ctrl-Shift. None of these bring up the debug screen for me in cpro.exe.

@joncampbell123: I am encouraged to see the screenshot you posted. I wonder what you are doing differently from what I'm doing?

@rderooy: I will read over the alternative key combinations link and see if there is something more I can test.

@Wengier: Did you ever get this to work on any of your machines? And, are you sure the update you posted here contained the correct DOSBox-X.exe? All I need to do is copy that exe into my DOSBox-X directory to get the updated code to work, right?

[joncampbell123]

I'm holding CTRL and pressing Pause/Break, as expected. Perhaps the OS is in the way? It works here on Linux.

[Wengier]

@zydanielson I never got the actual Ctrl+Break key to work for DOSBox-X on my machines. I did try to look for any 104-key USB keyboard that may be plugged into the laptop, but unfortunately I found none in my house even if I thought there may be at least one, and all I could find are PS/2 keyboards or so.

But I am sure the update I posted contained the latest code at that time. In order to make it easier to check the new Ctrl+Break handler, I think there is actually a very simple way to do this - I could in fact just add Ctrl+Break in the "Send special key" menu group for machines do not have such a key. So I did this. Please check out the updated DOSBox-X binary:

Download link: dosbox-x-update.zip

The thing is, sending the Ctrl+Break key from the menu apparently works (including Clarion) on both of the laptops I tried, but typing the actual Ctrl+Break key on the laptop did not. Both @joncampbell123 and @rderooy are apparently using Linux, but I am using Windows, so there is indeed the possibility that this issue is OS-specific.

[joncampbell123]

@Wengier That's a good idea, for the same reason emulators have a menu item to send CTRL+ALT+DEL when that key sequence is already taken by the OS.

[zydanielson]

@Wengier I am also on a Windows machine as is my client (his server and all his workstations).

Best news yet:

I confirm that Ctrl-Break from "Send Special Key" opens the debugger in cpro.exe on my machine. Once inside the debugger, everything I've tested works as expected. It is only a slight inconvenience that I can't open the debugger with a single keystroke. However, it is certainly one I can live with until I get smart like Jon and Robert and switch over to Linux. LOL

This also doesn't impact the runtime environment crun.exe; i.e., my client will never see this issue or its solution. But as far as I can tell, DOSBox-X will now run a complete Clarion 2.1 Professional Developer environment, as well as all programs written using it in both the runtime (crun.exe) and processor (cpro.exe). I will now begin exhaustive testing of all programs in my client's system written in Clarion 2.1 and in use for the past 30 years. Unless I post another issue, I now consider DOSBox-X a full and complete solution for Clarion 2.1.

My client, Brecon Knitting Mill, Inc., should also be considered a showcase in support of DOSBox-X being the leading DOS emulator for DOS applications, development, and support.

Allen, President of Brecon Knitting Mill, is delighted that his old system is running and will continue to run regardless of whether he stays with Microsoft or chooses to leave it behind. I don't know if he would move to macOS or Linux. But he is very glad to have the option. Allen and I are both quite happy with DOXBox-X and with the support we've received from all of you. I'm sure he would want me to tell you so.

@joncampbell123, @Wengier, @rderooy: Thank you.

This issue may be considered closed with this post. However I'll leave it open for a couple days in case any of you want to leave a closing thought.

[Wengier]

@zydanielson I am so glad to hear that it now works for you. I think even the slight inconvenience you mentioned can be overcome by using the mapper function to bind that menu item (so that you can define your own key to activate that function). But since there are already a lot of items in the mapper, I hope the interface can be cleaned up slightly.

@joncampbell123 Thank you so much for implementing the new Ctrl+Break handler! It is certainly a useful function for DOS applications in general.

@rderooy Thank you for the all the testing and suggestions you have made.

[rderooy]

Regarding the Break key in Windows, does this work for you: https://answers.microsoft.com/en-us/windows/forum/windows_7-hardware/query-about-pausebreak-key-on-the-keyboard/1edf2de8-5e4c-412e-b324-0b7b2242a60d

[joncampbell123]

I'm glad it works for you, however I've been doing some research into what DOSBox-X is doing wrong relative to real hardware and here are some notes:

• INT 21h AH=6 is not supposed to check CTRL+BREAK (which I fixed).
• CTRL+C or CTRL+BREAK always inserts byte 0x03 into the console input. Since INT 21h AH=6 does not check break, it is returned to you as byte 0x03. This is true of both IBM PC and PC-98 MS-DOS. DOSBox-X currently does not inject 0x03 if CTRL+BREAK is entered, but does for CTRL+C. DOSLIB hexstdi6.c confirms this, though if you hit CTRL+C/CTRL+BREAK while it's writing text to screen via printf(), you will break out of the program.
• Contrary to how the DOS console driver in DOSBox-X does it, MS-DOS's CON driver actually polls with INT 16h AH=11h to check for input first before reading input. This also allows it to check for CTRL+BREAK and respond. DOSBox-X uses AH=10h which blocks until input, requiring hacks like injecting 0x0000 into the keyboard buffer in order to respond to CTRL+BREAK properly.
• PC-98 emulation has a similar bug in DOSBox-X where STOP does not immediately signal break until you hit another key.

MS-DOS's behavior on the IBM PC suggests that perhaps if you type CTRL+BREAK, INT 16h wouldn't return anything (instead of DOSBox-X injecting 0x0000 into the keyboard buffer). I'm going to pull out the trusty old 486 laptop to confirm this.

[zydanielson]

@joncampbell123: This is a very old issue, I think. Even in the old days (back in the 90s) I remember that the debugger didn't always pop up with pressing Ctrl-Break. But I did notice that on the next keystroke it would always pop up. So I got in the habit of pressing Ctrl-Break and if nothing happened, pressing one of the arrow keys. So bringing up the debugger was sometimes a one keyclick thing and other times a two keyclick thing. Don't know if this is helpful info for you or not, but thought I would mention it.

[joncampbell123]

@zydanielson I ran MS-DOS 5.0 and 6.22 in DOSBox-X's debugger and asked it to break on INT 16h. When you're idle at the DOS prompt or any DOS application that reads the console input, MS-DOS is polling INT 16h AH=11h. If that function indicates a key, it calls INT 16 AH=10h to read it. In that way, MS-DOS is checking for BIOS keyboard input in a non-blocking manner that also allows it to check other flags, such as the one set by INT 1Bh.

I also ran DOSLIB's HEXSTDI6.EXE which uses INT 21h AH=6h to verify that behavior under MS-DOS 5.0, which shows it returns 0x03 (CTRL+C) for either CTRL+C or CTRL+BREAK.

DOS couldn't do that if it were using the blocking version of the function, INT 16h AH=10h

[Wengier]

@zydanielson I have already enhanced the mapper "SendKey" function so that you can now select a special key (such as Ctrl+Break) to be sent from the shortcut defined in the mapper editor (F11/F12+Delete by default). Select it from the "Send special key" menu group or by setting e.g. "mapper send key=ctrlbreak" in the configuration. With this you can now define your own key to act as the Ctrl+Break key to be sent to the program. Please check out the latest Windows binary:

Download link: dosbox-x-update.zip

@joncampbell123 I certainly hope to make DOSBox-X behave even more like in real DOS. Users who run DOS applications, Win3.x/9x etc in DOSBox-X will feel more like they are running the software in a real DOS system, which is loved by us.

@rderooy The Windows on-screen keyboard won't send Ctrl+Break key to the DOSBox-X window, unfortunately.

[Wengier]

I have modified the DOS error message from "Illegal command" to "Bad command or filename", as the latter is what is supposed to show to the user in real DOS. I hope to find more to fix as well.

@zydanielson Please let us know how the updated DOSBox-X binary works. Thanks!

[zydanielson]

@Wengier: Post edited. See comment below.

P.S. Sorry for taking so long to respond. We are about 15 miles from a fast spreading mountain wildfire. Sky is black with smoke and orange/red on the horizon. If we have to leave suddenly, I'll be grabbing my computer, then ourselves and the puppy ... in that order. LOL

[zydanielson]

@Wengier: Never mind about previous post. I found the documentation on the mapper in the wiki. I didn't ever hit save before, so I assume nothing I might have changed got saved. If that's true, no reset is necessary. I change the config mapper send key=ctrlbreak and was able to Add the key combination Alt-D to sendkey. I saved that and now Alt-D does call up the Clarion debugger in cpro.exe. Hope this was what you meant for me to do. It seems to work, anyway.

Question: will my mapping hold between updates? Or will I have to go through this each time?

[Wengier]

@zydanielson Yes, that is exactly how it is supposed to work. You can define any key you want in the mapper for the function of course.

The mapper will save the file named mapper-0.83.7.map (or so), which is enabled by the mapperfile config option. As long as you use that mapper file, it should work between updates. Keep a backup of the file when you have finished the mapper customization. Hope this helps.

[zydanielson]

@Wengier: Thanks. While we're on the subject of upgrades, I changed mapperfile=mapper-0.83.6.map in my config option to mapperfile=mapper-clarion.map which is a copy of my modified mapping. I have kept another copy of mapper-clarion.map outside the DOXBox-X folder for backup. If I use the windows installer to install a future major upgrade, I assume the installer won't delete my modified mapper file, right? And if it offers to convert my config, will it leave the mapperfile=mapper-clarion.map the way it is now? In other words, will it be safe to use the windows installer for future upgrades without having to modify the mapper again?

Up until now, when you have posted an upgrade here, I've just copied DOSBox-X.exe to my present DOSBox-X folder. I just want to be sure doing a full install using the windows installer will work as I said above.

[Wengier]

@zydanielson Sure, the installer is designed to be fully automatic. The config settings are supposed to be kept as-is like I mentioned earlier. Having to do manual steps will defeat the purpose of such an installer.

[zydanielson]

Thank you @Wengier. I was confident this is how you would respond. I just wanted to be certain one last time. I won't ask you this question in the future. :)

I'm so happy with all that's been done here. This is almost like being transported to the good-old-days of Clarion 2.1 programming!