Archive > Archived Posts

An Unicode reflexion

(1/9) > >>

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


[0] Message Index

[#] Next page

Go to full version