Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Developing U++ » Mac OS » Problem with menu accelerators
Problem with menu accelerators [message #50350] Mon, 01 October 2018 16:46 Go to next message
Novo is currently offline  Novo
Messages: 1358
Registered: December 2006
Ultimate Contributor
I'm getting a weird problem with menu accelerators.
index.php?t=getfile&id=5672&private=0
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 #50352 is a reply to message #50350] Wed, 03 October 2018 09:26 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
First of all, it is all in intense and turbulent development, please make sure you are using the trunk....

Anyway, accelerators are inserted as UTF8 unicode characters. This looks like this UTF8 is not interpreted correctly. Is your app running in CHARSET_UTF8?

(All that said, I am now at the final problem - implementing the "mac style" menu using NSMenu and NSMenuItem...)

Mirek

Report message to a moderator

Re: Problem with menu accelerators [message #50359 is a reply to message #50350] Wed, 03 October 2018 15:46 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1358
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

Report message to a moderator

Re: Problem with menu accelerators [message #50360 is a reply to message #50352] Wed, 03 October 2018 17:15 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1358
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

Report message to a moderator

Re: Problem with menu accelerators [message #50361 is a reply to message #50360] Wed, 03 October 2018 17:42 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Novo wrote on Wed, 03 October 2018 17:15
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.


That would be hard to integrate ("shouldn't rely" part).

I think we should just deprecate SetDefaultCharset.

Report message to a moderator

Re: Problem with menu accelerators [message #50363 is a reply to message #50361] Wed, 03 October 2018 19:48 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1358
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

Report message to a moderator

Re: Problem with menu accelerators [message #50364 is a reply to message #50361] Wed, 03 October 2018 20:03 Go to previous messageGo to next message
Zbych is currently offline  Zbych
Messages: 325
Registered: July 2009
Senior Member
mirek wrote on Wed, 03 October 2018 17:42
I think we should just deprecate SetDefaultCharset.


Guys maintaining old windows software after you did it:
index.php?t=getfile&id=5674&private=0

[Updated on: Wed, 03 October 2018 20:05]

Report message to a moderator

Re: Problem with menu accelerators [message #50365 is a reply to message #50363] Wed, 03 October 2018 20:22 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Novo wrote on Wed, 03 October 2018 19:48
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 ...


Well, the place is "Ctrl::GetKeyDesc". I am really not sure how reasonably fix it, except maybe reverting to text names ("Ctrl"...) if charset is not UTF8 (but even that will some people report as bug).

I understand the need for maintaining charsets for old apps - in windows. But I do not think that spending much effort to make U++/cocoa compatible with legacy encodings is worth it...

Report message to a moderator

Re: Problem with menu accelerators [message #50366 is a reply to message #50364] Wed, 03 October 2018 20:23 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Zbych wrote on Wed, 03 October 2018 20:03
mirek wrote on Wed, 03 October 2018 17:42
I think we should just deprecate SetDefaultCharset.


Guys maintaining old windows software after you did it:
index.php?t=getfile&id=5674&private=0


Deprecate is not "remove".

Mirek

Report message to a moderator

Re: Problem with menu accelerators [message #50368 is a reply to message #50350] Thu, 04 October 2018 10:41 Go to previous messageGo to next message
mr_ped is currently offline  mr_ped
Messages: 825
Registered: November 2005
Location: Czech Republic - Praha
Experienced Contributor
I 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.

Report message to a moderator

Re: Problem with menu accelerators [message #50370 is a reply to message #50368] Thu, 04 October 2018 12:44 Go to previous message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
mr_ped wrote on Thu, 04 October 2018 10:41
I 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.

Report message to a moderator

Previous Topic: GridCtrl is currently broken
Next Topic: The last roadbloack... workaround for NSMenu issue
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Tue Apr 16 23:05:40 CEST 2024

Total time taken to generate the page: 0.01073 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.5.
Copyright ©2001-2013 FUDforum Bulletin Board Software