Release version FP calculator

[hutch--]

Timo,

What I will do is add a setting so that the user has the choice, its a bit messy but I think it can be done. What I don't know yet is if the VC runtime conversion I am using will accept "," rather than ".".  I can change it on the fly both ways but it would be no joy to do.

[aw27]

VK_DECIMAL is floppy (depends on the keyboard and/or on the running application) - can't be trusted. It is not a driver issue - drivers know nothing about locales.

In what way?
If it works about in 99% cases, it should be good enough for normal user.
I was after a keyboard usage, not how to show numbers.

It very rarely works. Usually work in Excel does not work in Notepad. There are mentions on that on the internet, if you bother to use a search engine, instead of inventing statistics.

[TimoVJL]

Ok, it depends of NumLock state, without NumLock that key have value 2Eh Del.
I shall remove that false statistics.

[aw27]

Not a question of NUMLOCK, if NUMLOCK is OFF it deletes the character as expected  :shock:, if NUMLOCK is ON it frequently prints a period even in a non-US keyboard with the locale set for decimal character being a comma.  :shock:
All depends on the keyboard hardware and/or on the application handling.   :t

Does not work in Notepad but works in Calculator when I define the decimal separator as ☺.



That's all Folks!

[aw27]

Testing more potential decimal separators to be used with VK_DECIMAL
☺ ☻
Other cool Unicode chars can't be posted on this board (strange)

[aw27]

I can post one like this .

Nope, I can't - it shows in Preview but does not post. May be Mikl__, the icons expert, knows how to do it.

[TimoVJL]

Example to switch numpad comma to period.

Code: [Select]

GetLocaleInfo(LOCALE_USER_DEFAULT, LOCALE_SDECIMAL, szDes, 4);
...
LRESULT CALLBACK NewEditProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
switch(uMsg) {
case WM_CHAR:
if (wParam == ',') return 0;
break;
case WM_KEYUP:
if (wParam == VK_DECIMAL) {
if (szDes[0] != '.')
PostMessage(hWnd, WM_CHAR, '.', 0);
return 0;
}
break;
}
return OldEditProc(hWnd, uMsg, wParam, lParam);
}
EDIT: that msvcrt locale issue for user language:

Code: [Select]

setlocale(LC_NUMERIC, "");but then the constants needs to fix.
EDIT: useless code removed: uMsg == WM_KEYUP &&

[aw27]

It is interesting that in Windows (8.1 and 10, does not work in Windows 7 and below) we can have UTF-32 decimal separators. However, neither Calculator, nor Excel are able to render it when we press the VK_DECIMAL button on the NumPad - Shame!   . Probably they will do it in Windows 11. 

I post here a demo where an edit box prints the Mizaru (the wize monkey that covers his head) Unicode symbol when we press the VK_DECIMAL button on the NumPad. I include only the .exe and leave this a challenge for someone to elaborate on the subject (UTF-32, after BMP - Basic Multilingual Plane).

The demo saves the existing decimal separator character and sets Mizaru as decimal separator. When closing the application the original decimal separator is restored - so it is clean.
BTW, the demo is a little sized because was developed in Pascal for speed.



BTW, this SMF forum board does not accept as well posts with UTF-32 characters - this explains the problems I had yesterday.

[TimoVJL]

Timo,

What I will do is add a setting so that the user has the choice, its a bit messy but I think it can be done. What I don't know yet is if the VC runtime conversion I am using will accept "," rather than ".".  I can change it on the fly both ways but it would be no joy to do.

use

Code: [Select]

setlocale(LC_NUMERIC, "");and with sprintf(tmp, "%f", 1.2) you can verify that decimal separator, that you need for edit control subclassing.

EDIT: someone trusted user in this site have to confirm that, as i am just a hobbyist programmer.
EDIT: msvcrt.dll: C programmers can get decimal separator with: char cDS = **(char**)localeconv();

Code: [Select]

call localeconv
mov rax, qword ptr [rax]
mov al, byte ptr [rax]
move byte ptr [cDS], al

[hutch--]

Timo,

It will have to wait for the next one, the structure of the app is too complicated to try and change it and it would go back through every part down to the library modules. It already has a busy subclass for the rich edit control which is controlled by keystrokes but the main complexity in the app is the interface, the maths is reasonably simple. I have the settings working fine as the app was designed in the first place for it.

[TimoVJL]

Ok,
as sprintf() and  sscanf() follows that locale settings, only the edit subclass code needs to check if decimal separator is not the '.' and change that accepted chars?
Am i right, experts shall check it.

Those constant also as being string needs a special handling after that.

[hutch--]

I think its cleaner and simpler to make a setting as you can simply change the method of separation with optional code based of a simple flag. This app was written with multiple locations writing to the edit control and it would have been easier to write a new app than try and redesign the existing one. With a new app, isolating the text entry input to a single procedure would make it much simpler to handle the difference by a simple setting.

[aw27]

Example to switch numpad comma to period.

Code: [Select]

GetLocaleInfo(LOCALE_USER_DEFAULT, LOCALE_SDECIMAL, szDes, 4);
...
LRESULT CALLBACK NewEditProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
switch(uMsg) {
case WM_CHAR:
if (wParam == ',') return 0;
break;
case WM_KEYUP:
if (wParam == VK_DECIMAL) {
if (uMsg == WM_KEYUP && szDes[0] != '.')
PostMessage(hWnd, WM_CHAR, '.', 0);
return 0;
}
break;
}
return OldEditProc(hWnd, uMsg, wParam, lParam);
}

1)
You should check for VK_DECIMAL on the WM_KEYDOWN case statment not on the WM_KEYUP, and set a flag to be looked at in the WM_CHAR case statement. The way you put it does not appear to work  (in addition to be clunky). People would expect you to test the code you post, we don't need experts providing untested tips and ask others to check if they work or not.

2)
switch(uMsg){
...
   case WM_KEYUP:
   ...
      if (uMsg == WM_KEYUP // Does this mean that uMsg might be not  WM_KEYUP here?

Take care.

[Adamanteus]

Hutch - some questions :
1) My VS2008 ML64, truly not understand what is it :

Code: [Select]

msgloop proc

    USING r14,r15 - looks, like mought bo so :

Code: [Select]

msgloop proc USES r14 r152) also it not understand xmm registers, as .XMM - not works in it, so I changed all computations on FPU - but example of SSE anyway is excellent
3) default font charset - better avoid, as it looks not well on me, so better to local procedure :
font_handle - CreateFont,fHgt,0,0,0,fWgt,0,0,0,ANSI_CHARSET
4) and focus on edit, I used to put by mouse :

Code: [Select]

        invoke SendMessage,hEdit,EM_SETMARGINS,EC_LEFTMARGIN or EC_RIGHTMARGIN,eax
        invoke SetFocus, hEdit

[hutch--]

Use a later version of MASM. The old ones will not do the later stuff. It looks like you tried to build the app without the correct files and libraries available. Unless you have downloaded the most recent version of the MASM64 project here you cannot build it. This means both the latest macro file, the latest MASM64 libraries and to build them you need a reasonably recent version of ML64, LINK and RC as binaries.

I got the latest with the VS Build tools which was a bit over 1 gig.

I don't know what OS version you are running and further, did the original executable run on your machine ?