Home
>
WinDev Forum
>
Topic
Is it just me
Posted by Dimsa
|
Is it just me November 02, 2019 09:08PM |
Registered: 4 years ago Posts: 5 |
Greetings to all !
Can someone please confirm this (yet another) bug? I have a numeric field on screen. The project languages settings for Numbers are set to use operating system formats. So, nothing odd here. I have, of course, both decimal and thousand separator set, like, I believe, all of you have. Now, to the problem.
I enter number larger than 1000 (345.678,99 ie.). While entering, Windev doesn't show thousand separator (nothing wrong with that). But, when I leave the application window, and go to, lets say Calculator, and then go back to the field, I'm unable to continue typing, unless I overwrite the content. I cannot continue , I can see Windev restored thousand separator, and that, somehow, prevents any further changes, or continue of number entry. You can imagine the situation where one has to type a very large number, and has to switch to Calculator, Excel or whatever app., back and forth. I got this reported from one of my customers, I can confirm this really happening, I know it has something to do with thousand separater, but, honestly, I'm sick of re-programming every basic functionality in Windev because it either lacks it completely, or it is buggy as it is in this case.
Can someone please confirm this (yet another) bug? I have a numeric field on screen. The project languages settings for Numbers are set to use operating system formats. So, nothing odd here. I have, of course, both decimal and thousand separator set, like, I believe, all of you have. Now, to the problem.
I enter number larger than 1000 (345.678,99 ie.). While entering, Windev doesn't show thousand separator (nothing wrong with that). But, when I leave the application window, and go to, lets say Calculator, and then go back to the field, I'm unable to continue typing, unless I overwrite the content. I cannot continue , I can see Windev restored thousand separator, and that, somehow, prevents any further changes, or continue of number entry. You can imagine the situation where one has to type a very large number, and has to switch to Calculator, Excel or whatever app., back and forth. I got this reported from one of my customers, I can confirm this really happening, I know it has something to do with thousand separater, but, honestly, I'm sick of re-programming every basic functionality in Windev because it either lacks it completely, or it is buggy as it is in this case.
|
Re: Is it just me November 03, 2019 07:30AM |
Admin Registered: 5 years ago Posts: 501 |
Hi,
it's the way WINDOWS is working! There is NO BUG at all! Moving the FOCUS from one window to another window (= calculator) will fire the appropriate WINDOWS-events (of controls and the window itself) in the window left behind. Leaving an EDIT control with numeric format will switch it from input mode to display mode - automatically! That's a FEATURE, not an error. Indeed, if you want it to be ready for input on return there are a few choices
1 - the cheap one: use the built-in calculator button for edit-controls with numeric formatting!! This will place the result automatically into the edit control! (Calculator buttons are there since version 17 of WINDEV)
2 - if you really want to use an external calculator button then use "automation" (see WINDEV Help) which could place the calculation's result directly into the edit control. This could be very complex but also very simply like Ctrl-C & put edit in input mode & Ctrl-V
3 - For unusually complex problems you can write your own calculator window and place the result into the edit control
4 - You could use drag and drop to move a result from an external calculator window to the edit control too
Please, add the WINDEV version and the prioblem that you have to your postings, thank you!
Example: [WD24] Losing focus of edit control
Kind regards,
Guenter Predl
office@windev.at
it's the way WINDOWS is working! There is NO BUG at all! Moving the FOCUS from one window to another window (= calculator) will fire the appropriate WINDOWS-events (of controls and the window itself) in the window left behind. Leaving an EDIT control with numeric format will switch it from input mode to display mode - automatically! That's a FEATURE, not an error. Indeed, if you want it to be ready for input on return there are a few choices
1 - the cheap one: use the built-in calculator button for edit-controls with numeric formatting!! This will place the result automatically into the edit control! (Calculator buttons are there since version 17 of WINDEV)
2 - if you really want to use an external calculator button then use "automation" (see WINDEV Help) which could place the calculation's result directly into the edit control. This could be very complex but also very simply like Ctrl-C & put edit in input mode & Ctrl-V
3 - For unusually complex problems you can write your own calculator window and place the result into the edit control
4 - You could use drag and drop to move a result from an external calculator window to the edit control too
Please, add the WINDEV version and the prioblem that you have to your postings, thank you!
Example: [WD24] Losing focus of edit control
Kind regards,
Guenter Predl
office@windev.at
|
Re: Is it just me November 03, 2019 03:58PM |
Registered: 4 years ago Posts: 5 |
Hello Guenter,
Thanks for the response. The advice taken. My WD version is 23, but I doubt anything changed in 24. Will it ever? I highly doubt, especially if they agree with you about the Windows feature. If you can give me an example where to see such implementation, please do.
To test, as you said the Windows feature, I've tried using MS Access. It should be a very representative windows application. I also tested application written in a different RAD tool I wouldn't mention here because I've seen argues here not ending well .... And, it works like charm. I didn't want to investigate any further. No problems detected, when I leave a numeric field, cursor stays in the same position when I come back, with no changes in display format. I can continue entering number where I left. I know it is definitely a problem with the WD masks, because, once Windev switches to display mask on focus loss, thousand separator kicks in. The problem is, it doesn't go away when I re-enter the field, because no event is triggered except Gain Focus. Thousand separator then prevents me to type anything. I know I could say to my customers to overwrite thousand separators, or overwrite whole field, but I won't do that, because I respect their intelligence.
I'm not saying I cannot deal with the problem. Trapping event should solve it, but, as I said, I'm a little tired of re-programming events especially on a project level. Thanks for your suggestions, but there's one priority. My customers shouldn't notice any difference, neither on interface (calculator), nor functional (drag and drop).
Best regards,
Sasha
Thanks for the response. The advice taken. My WD version is 23, but I doubt anything changed in 24. Will it ever? I highly doubt, especially if they agree with you about the Windows feature. If you can give me an example where to see such implementation, please do.
To test, as you said the Windows feature, I've tried using MS Access. It should be a very representative windows application. I also tested application written in a different RAD tool I wouldn't mention here because I've seen argues here not ending well .... And, it works like charm. I didn't want to investigate any further. No problems detected, when I leave a numeric field, cursor stays in the same position when I come back, with no changes in display format. I can continue entering number where I left. I know it is definitely a problem with the WD masks, because, once Windev switches to display mask on focus loss, thousand separator kicks in. The problem is, it doesn't go away when I re-enter the field, because no event is triggered except Gain Focus. Thousand separator then prevents me to type anything. I know I could say to my customers to overwrite thousand separators, or overwrite whole field, but I won't do that, because I respect their intelligence.
I'm not saying I cannot deal with the problem. Trapping event should solve it, but, as I said, I'm a little tired of re-programming events especially on a project level. Thanks for your suggestions, but there's one priority. My customers shouldn't notice any difference, neither on interface (calculator), nor functional (drag and drop).
Best regards,
Sasha