Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: uCreateWindowEx and the like; what is its use now that ANSI OSes are d (Read 4754 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

uCreateWindowEx and the like; what is its use now that ANSI OSes are d

I thought that they were used for having a single plugin for both unicode and ansi OSes, as they were a wrapper for the real Windows API functions. But if foobar 0.9 only supports WinXP and 2k, and having into account that both OSes support unicode, what is the use of all those u* wrappers?

Thanks,
Jorge

uCreateWindowEx and the like; what is its use now that ANSI OSes are d

Reply #1 –
PFC and company still use UTF-8 internally, so all of those functions which accept strings still need UTF-8 to UTF-16 conversion, and all those which return strings perform the reverse conversion.

uCreateWindowEx and the like; what is its use now that ANSI OSes are d

Reply #2 –
But for example, if I use CreateWindowEx instead of uCreateWindowEx it shouldn't make any difference, right?

Thanks

uCreateWindowEx and the like; what is its use now that ANSI OSes are d

Reply #3 –
I will try to explain it further:

If all the strings used in a plugin are in UTF16 (all are generated by Visual Studio, and no one come from foobar sdk), there is no problem in using CreateWindowEx (and the like) instead of the utf8 versions, right?

uCreateWindowEx and the like; what is its use now that ANSI OSes are d

Reply #4 –
Don't forget about GetWindowText or SetWindowText. Unless you like translating the strings yourself, and in the case of GetWindowText, allocating buffers.

uCreateWindowEx and the like; what is its use now that ANSI OSes are d

Reply #5 –
But it your program is configured as unicode, there is no problem in passing utf16 strings (to be exact, ucs-2) to win32 api functions like SetWindowText or GetWindowText, or I am wrong? If so, using uSetWindowText or uGetWindowText offers no advantage over standard api functions.

uCreateWindowEx and the like; what is its use now that ANSI OSes are d

Reply #6 –
If you still don't understand the point of those functions being present, it should make no difference to you whether you use them or not.
Microsoft Windows: We can't script here, this is bat country.

uCreateWindowEx and the like; what is its use now that ANSI OSes are d

Reply #7 –
Quote from: Peter on
If you still don't understand the point of those functions being present, it should make no difference to you whether you use them or not.


Then, would you be so kind as to explain me the point of them?

uCreateWindowEx and the like; what is its use now that ANSI OSes are d

Reply #8 –
It has already been explained in posts above.
The fact that something is in shared.dll does not mean that using it is mandatory; under 0.9, these functions are provided as helpers to avoid having to code UTF-8/string_base <=> TCHAR conversion again and again every time you work with window titles or whatever and your backend uses UTF-8 strings.
Microsoft Windows: We can't script here, this is bat country.

uCreateWindowEx and the like; what is its use now that ANSI OSes are d

Reply #9 –
Quote from: Peter on
It has already been explained in posts above.
The fact that something is in shared.dll does not mean that using it is mandatory; under 0.9, these functions are provided as helpers to avoid having to code UTF-8/string_base <=> TCHAR conversion again and again every time you work with window titles or whatever and your backend uses UTF-8 strings.


As English is not my native Language, I think I have misunderstood the previous posts. But it's all clear now, thanks!