FMSLogo Code

Extend THROW so that it can be used to throw a localized "bad input" error. This was done so that the Logolib routines can throw bad input errors and still be language-neutral.

Fix typo in comment.

Fix bug #1609333; "Select Active Area" dialog box no longer loses UI elements after pressing CTRL+ALT+DELETE.

I'm not sure what the problem was, but it looked like Z-order of the sunken label that FMSLogo was using to etch a rectangular background somehow got moved ahead of some of the other UI elements. This feels more like an OS bug than an FMSLogo bug, but I was able to work-around the problem by using a groupbox, instead of a sunken static label.

Fix bug #1622721; FMSLogo no longer gets into a bad state when the clipboard becomes text.

The bug was that turtlepaint(), which is called from the WM_PAINT message handler, threw a stopping error. This stopping error would be misinterpreted when the editor was closed, as having originated while processing the contents of the editor.

The fix is to make turtlepaint() not throw a stopping error.

Add the framework needed for a Portuguese translation of FMSLogo.

Fix bug #1735569; When the clipboard contains text, running BITMAPTURTLE no longer prevents subsequent calls to BITMAPTURTLE from working.

The root of the bug is that, if FMSLogo has an unhanded "stop" error, the routine which implements BITMAPTURTLE would do nothing. In most cases, this is what we want, but in this case, the routine was called from the WM_PAINT message handler, not the Logo evaluator, so it would cause this bitmapped-turtle drawing part of WM_PAINT to do nothing. Every time a new instruction was run in the commander, it would save the current state of the "stopping_flag", run the command, then restore "stopping_flag". Then WM_PAINT would fire and this routine would see that FMSLogo was still in a stopping state and again, it would nothing. Once the stopping_flag was set, there was no way to unset it.

Depending on how you look at it, this could be considered a regression from MSWLogo. I had earlier fixed a bug where this condition would cause FMSLogo to have an unprocessed "halt" error, which caused the next command to always throw a stopping error. The fix was to backup and restore the state of stopping_flag while running any instruction from the commander. But because the stopping_flag is now always restored after it is run, the WM_PAINT message has no way of clearing it.

The fix for this bug is to ignore the state of stopping_flag from the context of WM_PAINT. The only time that this flag should be honored is if we're in the evaluator, in which case, it's used to ignore further Logo instructions.

Add the framework needed for a Portuguese translation of FMSLogo.

Add the framework needed for a Portuguese translation of FMSLogo.

Add a Portuguese translation of localizedstrings-en.h, courtesy of Alexandre Soare.

Fix bug #1765108; MACHINE now outputs the correct working area, even it it changed. FMSLogo also now positions new windows in the working area, even if the size of the desktop or taskbar has changed.

The fix was to always call SystemParametersInfo() to get the size of the current working area, instead of calling it once when the program starts up and using the cached values from then on.