|
|
Home » Developing U++ » Mac OS » Problem with menu accelerators
Problem with menu accelerators [message #50350] |
Mon, 01 October 2018 16:46 |
Novo
Messages: 1371 Registered: December 2006
|
Ultimate Contributor |
|
|
I'm getting a weird problem with menu accelerators.
The app is compiled with the "GUI SSE2 .USEMALLOC" flags.
The code is below.
menu.Add("Open file", THISBACK(OpenFile)).Key(K_CTRL_O);
menu.Add("Reread file", THISBACK(OnReRead)).Key(K_CTRL_R);
Accelerators in TheIDE look fine. What could possibly be wrong with my app?
Regards,
Novo
[Updated on: Mon, 01 October 2018 16:47] Report message to a moderator
|
|
|
|
Re: Problem with menu accelerators [message #50359 is a reply to message #50350] |
Wed, 03 October 2018 15:46 |
Novo
Messages: 1371 Registered: December 2006
|
Ultimate Contributor |
|
|
I'm always using the latest trunk.
My another app doesn't have such problem. In both apps file's charset is set to "Default".
In the TheIDE Setup -> Settings -> Editor -> Default charset is set to UTF8.
The app having problem with menu accelerators doesn't have this problem in Windows and in Linux. I'm distributing it for 7 years ...
The problem is not urgent. My app is free and I'm just reporting a possible bug.
I'll be waiting for NSMenu ...
Thank you for developing UPP and porting it to Mac!
Regards,
Novo
|
|
|
Re: Problem with menu accelerators [message #50360 is a reply to message #50352] |
Wed, 03 October 2018 17:15 |
Novo
Messages: 1371 Registered: December 2006
|
Ultimate Contributor |
|
|
mirek wrote on Wed, 03 October 2018 03:26
Anyway, accelerators are inserted as UTF8 unicode characters. This looks like this UTF8 is not interpreted correctly. Is your app running in CHARSET_UTF8?
Actually, it was running in CHARSET_WIN1250.
I was calling SetDefaultCharset(CHARSET_WIN1250), probably, for historical reasons.
I guess UPP shouldn't rely on default charset in places like menu accelerators.
Regards,
Novo
|
|
|
|
Re: Problem with menu accelerators [message #50363 is a reply to message #50361] |
Wed, 03 October 2018 19:48 |
Novo
Messages: 1371 Registered: December 2006
|
Ultimate Contributor |
|
|
mirek wrote on Wed, 03 October 2018 11:42
That would be hard to integrate ("shouldn't rely" part).
I think we should just deprecate SetDefaultCharset.
I somewhat doubt that deprecating of SetDefaultCharset is easier.
What will you do with functions taking CHARSET_DEFAULT as an argument?
CHARSET_DEFAULT should disappear in such case ...
IMHO, it is easier to fix places which explicitly require UTF8 ...
Regards,
Novo
|
|
|
|
|
|
|
Re: Problem with menu accelerators [message #50370 is a reply to message #50368] |
Thu, 04 October 2018 12:44 |
|
mirek
Messages: 14039 Registered: November 2005
|
Ultimate Member |
|
|
mr_ped wrote on Thu, 04 October 2018 10:41I think legacy SW should move to UTF8 finally, if-possible (development-time-budget wise)...
If it is not maintained any more, you can use old binaries for some time.
I'm not even sure how much dev effort it can take to migrate legacy code to UTF8, sounds to me like it should require just few text resources files conversion, setting UTF8 encoding for app environment, and finding string related code operating with byte = single letter assumption (if the legacy app was text editor, this may be problematic, otherwise you may have none such place in source = no work).
Sounds to me like for many apps this migration is 1-4h task + testing/bugfixing. Maybe 1-2 days in relaxed way.
...as long as it is just your code. Consider application connected to other subsystems, like SQL or perhaps some printing or OCR input or legacy 3rd party lib that you have no source code for (or maybe just not enough energy to fix and recompile) and things immediately become much more complicated.
|
|
|
Goto Forum:
Current Time: Sat Sep 21 03:30:19 CEST 2024
Total time taken to generate the page: 0.03970 seconds
|
|
|