Author Topic: An Unicode reflexion  (Read 23846 times)

0 Members and 1 Guest are viewing this topic.

Offline José Roca

  • Administrator
  • Hero Member
  • *****
  • Posts: 2481
  • User-Rate: +204/-0
An Unicode reflexion
« on: April 17, 2011, 09:58:02 PM »
 
Now that PB 10 has native unicode support, do you know of any reason, other than having to use WSTRING and WSTRINGZ instead of STRING and ASCIIZ, for having two declares, one for the “A” functions and another for the “W” functions? If we use WSTRING/WSTRINGZ aren’t the unicode declares enough? If I'm not wrong, what the API "A" functions do is to convert string parameters to unicode and call the "W" function, and with window messages: "The system does automatic two-way translation (Unicode to ANSI) for window messages. For example, if an ANSI window message is sent to a window that uses the Unicode character set, the system translates that message into a Unicode message before calling the window procedure. The system calls IsWindowUnicode to determine whether to translate the message. "

I'm asking just in case I'm missing something. Otherwise, we could remove all the ansi related stuff from the includes and PBer's only will need to get used to WSTRINGs and WSTRINGZs instead of STRINGs and ASCIIZs. This would have some benefits such as somewhat faster compiles (less stuff to parse) and the removal of a ton of #IF/ENDIFs and MACROs that can cause nesting overflows with programs that use many includes besides the API ones.

What do you think?

Offline Theo Gottwald

  • Administrator
  • Hero Member
  • *****
  • Posts: 918
  • User-Rate: +30/-4
    • it-berater
Re: An Unicode reflexion
« Reply #1 on: April 17, 2011, 10:07:58 PM »
I think it would be too fast. Maybe next version.
People are not so fast in changes. Not even Obama :-).

Offline José Roca

  • Administrator
  • Hero Member
  • *****
  • Posts: 2481
  • User-Rate: +204/-0
Re: An Unicode reflexion
« Reply #2 on: April 17, 2011, 10:24:50 PM »
 
I am.

Most people never accept changes unless they have to, but I'm a revolutionary.

Offline Frederick J. Harris

  • Hero Member
  • *****
  • Posts: 914
  • User-Rate: +16/-0
    • Frederick J. Harris
Re: An Unicode reflexion
« Reply #3 on: April 17, 2011, 10:28:16 PM »
What would happen if a CreateWindow or CreateWindowEx call were made on a custom control internally building and working with asci windows and parameters, for example this from one of my apps doing a CreateWindow call (which the PowerBasic includes - and I guess yours too, would have macro'ed to CreateWindowEx)....

hGrid=CreateWindow("SIGrid",ByVal StrPtr(strColSetup),dwGrdStyle,530,20,515,260,Wea.hWnd,%IDC_PULPTALLY_GRID,hIns,ByVal VarPtr(Grids))

In the above code strColSetup is a regular pre - PB 10 ansi dynamic string.  The SIGrid custim control uses the Window Caption parameter of the CreateWindow call to pass in a string containing grid column information, i.e., column widths in pixels, grid column caption, etc.  I haven't tried it, but I'm guessing it wouldn't work as a CreateWindowExW call?

Offline Edwin Knoppert

  • Sr. Member
  • ****
  • Posts: 254
  • User-Rate: +11/-4
    • Hellobasic.com
Re: An Unicode reflexion
« Reply #4 on: April 17, 2011, 10:29:08 PM »
Frankly the whole 2 mechanism matter makes it hard to make the move.
To be honest, i have no pressure to make the move, i still work with v9.01 since the others had a variant bug (the webbrowser issue ever mentioned).
The new version make this really hard on my existing code and there is no simple "if it runs why bother?" because i need guarantees i can control and fix all parts of my code.
Currently some of my code runs unpredictably and some of my code is purely ansi based and i don't see a way to rewrite it without messing up other parts.
I think the switch to unicode is just a leap to far on existing projects.
So far i can't see the whole picture.

If you want to remove the ansi stuff from your includes, be my guest, i can only recommend it (without considerations though).

Offline Edwin Knoppert

  • Sr. Member
  • ****
  • Posts: 254
  • User-Rate: +11/-4
    • Hellobasic.com
Re: An Unicode reflexion
« Reply #5 on: April 17, 2011, 10:30:18 PM »
>Frederick
Yes interesting subject, mixing unicode and ansicode controls.

Offline José Roca

  • Administrator
  • Hero Member
  • *****
  • Posts: 2481
  • User-Rate: +204/-0
Re: An Unicode reflexion
« Reply #6 on: April 17, 2011, 11:02:06 PM »
What would happen if a CreateWindow or CreateWindowEx call were made on a custom control internally building and working with asci windows and parameters, for example this from one of my apps doing a CreateWindow call (which the PowerBasic includes - and I guess yours too, would have macro'ed to CreateWindowEx)....

hGrid=CreateWindow("SIGrid",ByVal StrPtr(strColSetup),dwGrdStyle,530,20,515,260,Wea.hWnd,%IDC_PULPTALLY_GRID,hIns,ByVal VarPtr(Grids))

In the above code strColSetup is a regular pre - PB 10 ansi dynamic string.  The SIGrid custim control uses the Window Caption parameter of the CreateWindow call to pass in a string containing grid column information, i.e., column widths in pixels, grid column caption, etc.  I haven't tried it, but I'm guessing it wouldn't work as a CreateWindowExW call?


Conversion to unicode is automatic unless you override it with byvals and pointers. If the control wants ByVal StrPtr(strColSetup) then use ByVal StrPtr(strColSetup). CreateWindowEx will just pass your pointer.

« Last Edit: April 17, 2011, 11:04:16 PM by José Roca »

Offline Frederick J. Harris

  • Hero Member
  • *****
  • Posts: 914
  • User-Rate: +16/-0
    • Frederick J. Harris
Re: An Unicode reflexion
« Reply #7 on: April 17, 2011, 11:20:07 PM »
I take back that comment I made several weeks ago when Theo was going on about this being the biggest PowerBASIC release ever, and I said I thought PB 5 - 9 (objects) was the biggest release.   I've pretty much been floundering ever since I got it.  Its been the biggest release ever.

Tomorrow I'll try that code Jose and see what happens.  I agree with you that the function will pass a pointer and its up to whatever receives the pointer to act on it and interpret it as it likes (a ptr to unicode or ansi characters).

If you were to remove ansi declares from your includes it wouldn't mean they couldn't be used; one would simply need to declare them oneself I guess (if one wanted to use some).

Offline José Roca

  • Administrator
  • Hero Member
  • *****
  • Posts: 2481
  • User-Rate: +204/-0
Re: An Unicode reflexion
« Reply #8 on: April 17, 2011, 11:24:42 PM »
 
Regarding the Windows API, everything seems to have been solved by M$, so the duplicity of ansi and unicode functions seems unneeded other than for legacy code. The only API function with a string parameter that I know that is only ansi is GetProcAddress. But this is not a problem: When a function needs an ansi string, just pass an ansi string or force automating conversion using BYCOPY. Even DDT is now fully unicode.
« Last Edit: April 18, 2011, 12:25:13 AM by José Roca »

Offline José Roca

  • Administrator
  • Hero Member
  • *****
  • Posts: 2481
  • User-Rate: +204/-0
Re: An Unicode reflexion
« Reply #9 on: April 17, 2011, 11:33:31 PM »
Quote
If you were to remove ansi declares from your includes it wouldn't mean they couldn't be used; one would simply need to declare them oneself I guess (if one wanted to use some).

Of course, but the question is to ascertain if it is needed or not. My headers already have both the ansi and unicode stuff, so removing the ansi one is a lot of extra work. But I have some good reasons for it. The price to pay: to take the habit of using WSTRING and WSTRINGZ when calling API functions. You can also use STRING and ASCIIZ and pass them with BYCOPY, but this is as innefficient as calling the "A" functions because they have to be converted to unicode.

Offline Theo Gottwald

  • Administrator
  • Hero Member
  • *****
  • Posts: 918
  • User-Rate: +30/-4
    • it-berater
Re: An Unicode reflexion
« Reply #10 on: April 18, 2011, 12:43:27 AM »
As said, Jose. I'd leave it in this time and if you make new headers then make the extra jump.
To do things with an educational idea in mind ist most often a concept that does not work out at the end - if it has to do with a broader public.

the only reason you could have to do so, would be if you are afraid that nobody will use the other available includes anymore, so you make yours more difficult to use for beginners this way. And you reduce the capability to use old code.

Offline José Roca

  • Administrator
  • Hero Member
  • *****
  • Posts: 2481
  • User-Rate: +204/-0
Re: An Unicode reflexion
« Reply #11 on: April 18, 2011, 01:31:40 AM »
 
Old code must be compiled with old headers. We must not work for the rearmost student of the class if we want to progress. For new code, i don't think that using WSTRING and WSTRINGZ instead of STRING and ASCIIZ requires a lot of effort. It is a pain for me that each time that I write a new wrapper function I have to write and test an ansi and an unicode version, specially since there is not any advantage in using the ansi version.


Offline José Roca

  • Administrator
  • Hero Member
  • *****
  • Posts: 2481
  • User-Rate: +204/-0
Re: An Unicode reflexion
« Reply #12 on: April 18, 2011, 03:59:53 AM »
You already have to work with unicode to use COM, and the ansi functions of the Windows API are just wrappers for the unicode one. I could just leave them, but if the main window and the controls are created with CreateWindowExA instead of CreateWindowExW, then you have to provide both ansi and unicode versions for each wrapper function you write that deals with windows and controls. Even DDT is now fully unicode, and those using the ansi versions with a DDT dialog can have problems. Unicode should have been implemented ten years ago, long before COM. We have been using COM with ansi strings, UCODE$/ACODE$ and STRPTRs. And low-level COM was very hard to use because the lack of unicode null-terminated strings.

Offline Theo Gottwald

  • Administrator
  • Hero Member
  • *****
  • Posts: 918
  • User-Rate: +30/-4
    • it-berater
Re: An Unicode reflexion
« Reply #13 on: April 18, 2011, 07:53:43 AM »
Code: [Select]
Yeah, I was thinking "no" at first... but now... if people want ANSI, they can just use the PowerBASIC headers... right?
What about Visual Designer?
I can perfectly use the current Header from Jose togethe with Fire Fly 3.
It's just compatible.

Will it still work without lot's of changes if Jose makes a revolution?
I can't influence the cdoe a VD generates.

I like the current situation, and will keep the actual headers anyway.
They exist they are available.

If Jose will make new headers I'll possibly also use them, but keep the actual once.

And then we have header Nr.3 which increases the "header chaos".
Means its good that we have CSED with the Option to put the actual used header from the actual project into the current project folder.

For a newcomer such things are the biggest obstacles. If there are many alternatives and he has no guide(line) how to easily start. I understand the sort of simplification that Jose thinks about and also to me it has "something".

But it should be not by force but as an Option. Users do not like to be forced.
« Last Edit: April 18, 2011, 10:35:42 AM by Theo Gottwald »

Offline José Roca

  • Administrator
  • Hero Member
  • *****
  • Posts: 2481
  • User-Rate: +204/-0
Re: An Unicode reflexion
« Reply #14 on: April 18, 2011, 08:25:50 AM »
Quote
What about Visual Designer?
I can perfectly use the current Header from Jose togethe with Fire Fly 3.
It's just compatible.
Will it still work without lot's of cahnges if Jose makes a revolution?

But we have "revolutionary" plans for FF4 :) C'est la guerre!

Quote
For a newcomer such things are the biggest obstacles. If there are many alternatives and he has no guide(line) how to easily start. I understand the sort of simplification that Jose thinks about and also to me it has "something".

Actually, the ones that complain are the "old farts", worried about his legacy code. But "The Times They Are A-Changin" and we need new tricks.

Quote
I understand the sort of simplification that Jose thinks about and also to me it has "something".

What about classes for GDI+ very similar to the C++ ones, but High DPI aware?

I want to make easy to write new applications that are both Unicode and High DPI aware.