Got it.
Printable View
Got it.
Ok, so this update contains the implementation for 'EvalExpr', and the 'LET' command, plus some other minor changes. Let me know if I broke anything. :D
Paul, just thought I'd let you know that it still has a way to go before you'll be able to test it out, but it is coming along...
Ok, thanks Sebastiani.
Paul
I took a look at the code... the original is a bad dog.
Before I jump into this, which I may if time allows, may I at least suggest updating the API test to do something useful?
Soma
Code:void mbox_error_handler
(
const std::string & from_f,
const std::size_t where_f,
const bool show_f
)
{
if(show_f)
{
const DWORD buffer_length(256);
char message_buffer[buffer_length];
const DWORD characters_written = FormatMessageA
(
FORMAT_MESSAGE_FROM_SYSTEM,
0, // lpSource (ignored here)
GetLastError(),
0, // dwLanguageId (use system defaults)
message_buffer,
buffer_length,
0 // Arguments (pointless VA_LIST nonsense)
);
std::ostringstream message;
if(0 == characters_written)
{
message
<< "File: " << from_f << '\n'
<< "Line Number: " << where_f << '\n'
<< "Error Message:\n"
<< "unknown exception"
;
}
else
{
message_buffer[characters_written - 2] = 0;
message
<< "File: " << from_f << '\n'
<< "Line Number: " << where_f << '\n'
<< "Error Message:\n"
<< message_buffer
;
}
MessageBoxA
(
0, // hWnd (no owner)
message.str().c_str(),
"WIN32API Exception",
MB_ICONERROR | MB_OK | MB_TASKMODAL
);
}
}
#define WINAPITEST(BADVALUE, RESULT) mbox_error_handler(__FILE__, __LINE__, BADVALUE == RESULT)
>> I took a look at the code... the original is a bad dog.
I couldn't agree more.
>> may I at least suggest updating the API test to do something useful?
That's a good idea. And since API errors are basically fatal, you might as well just have the program die at that point.
Agreed - I was going to do something like that, but I hadn't got round to it.
Can we just do a small change:
By putting names there, it's easier to see what is what.Code:#define WINAPITEST(RESULT, EXPECTED) mbox_error_handler(__FILE__, __LINE__, RESULT == EXPECTED)
--
Mats
I'm pretty sure I said something like that when I started the work - it's definitely not easy-to-follow, straight-forward assembly code. Lots of jumps. One of my favourites was a bit that didto skip over a jmp instruction in the calling code. That is hard to achieve in C or C++.Code:pop ebx // get return address
add ebx, 2
jmp ebx
I'm going to have a quick look at Sebastianis change's, but do not expect me to do much with it until Monday.
In the mean-time, keep up the good work.
--
Mats
Ok, thanks.
Paul
A couple of comments on the updated code:
1. what is #include <std> for?
2. In VS 2008, the loss of const in RedimWindow() doesn't work.
I also think we should keep the functionality of RedimWindow - there is a "WINDOW" command in the language itself that uses it. I believe existing code would break if you remove that command.
It may well be that some situations do not allow completely free re-sizing of windows, but it should still be there for those apps that can/want to do it.
--
Mats
Oh, the header include was just for debugging purposes. Ignore it.
As far as RedimWindow goes, it just needs to be restructured so that it takes on a default value when the program starts up, and then if the user tries to resize the window and it fails, it just reverts back to the default without causing a fatal error.
For some reason the documentation in MBI.zip doen't list all of the functions (such as WINDOW, LOCATE, etc). Anyone have a complete listing?
Ha! Yeah, I admit it, I was trying to avoid looking at the assembly...:D
BTW, Are PEEK and POKE supposed to refer to the @ variable?