An Unicode reflexion

[José Roca]

 
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?

[Theo Gottwald]

I think it would be too fast. Maybe next version.
People are not so fast in changes. Not even Obama :-).

[José Roca]

 
I am.

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

[Frederick J. Harris]

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?

[Edwin Knoppert]

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).

[Edwin Knoppert]

>Frederick
Yes interesting subject, mixing unicode and ansicode controls.

[José Roca]

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.

[Frederick J. Harris]

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).

[José Roca]

 
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.

[José Roca]

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.

[Theo Gottwald]

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.

[José Roca]

 
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.

[José Roca]

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.

[Theo Gottwald]

Code Select Expand

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.

[José Roca]

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!

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.

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.