Skip to main content
Topic: Few questions (Read 4313 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Few questions

1. Is it possible to wait until configuration of the plugin is loaded?
I'd like to access it ASAP (in initquit or WM_CREATE) without polling for a change in known value.

2. This code produces a window with title 'f'... Is there anything I can do to get whole title?
Code: [Select]
void initquit(bool is_init)
{
 if (is_init)
 {
  uWNDCLASS wc;
  memset(&wc, NULL, sizeof(wc));
  wc.hInstance=core_api::get_my_instance();
  wc.lpszClassName="FooTimerWindow";
  wc.lpfnWndProc=TimerWindowProc;
  uRegisterClass(&wc);
  wnd_main=uCreateWindowEx(0, "FooTimerWindow", "foo_timer", WS_VISIBLE, 0, 0, 0, 0, core_api::get_main_window(), NULL, core_api::get_my_instance(), NULL);
 }
 else
 {
  UnregisterClass("FooTimerWindow", core_api::get_my_instance());
 }
}

static initquit_simple meh(initquit);

Normally this window will be invisible anyway, but I'm curious about what causes the bug.
If placed in DLLMain without core_api calls, it also produces window with such title...
Changing API calls to plain Windows ones doesn't help too... Is it a compiler bug or have I done something wrong?

I'm using Visual C++ 6 Service Pack 5 Standard.
ruxvilti'a

Few questions

Reply #1
I guess the 'u' in uCreateWindowEx stands for Unicode. I am no Unicode guru, but the string literals you build are ANSI ones, and I think you should insert a 'L' in front of their definition like:

Code: [Select]
wnd_main=uCreateWindowEx(0, L"FooTimerWindow", L"foo_timer", WS_VISIBLE, 0, 0, 0, 0, core_api::get_main_window(), NULL, core_api::get_my_instance(), NULL);


or

Code: [Select]
wc.lpszClassName=L"FooTimerWindow";


Quote
Changing API calls to plain Windows ones doesn't help too...


Because your build is an Unicode one, and most of Windows API function names are just proxy (in fact macros) for their ANSI/Unicode counterparts depending on the build options.

Few questions

Reply #2
Quote
I guess the 'u' in uCreateWindowEx stands for Unicode. I am no Unicode guru, but the string literals you build are ANSI ones, and I think you should insert a 'L' in front of their definition like:

Code: [Select]
wnd_main=uCreateWindowEx(0, L"FooTimerWindow", L"foo_timer", WS_VISIBLE, 0, 0, 0, 0, core_api::get_main_window(), NULL, core_api::get_my_instance(), NULL);


or

Code: [Select]
wc.lpszClassName=L"FooTimerWindow";

Nope, 'u' is for UTF-8, so AstralStorm's API calls are correct in that aspect.

Quote
Quote
Changing API calls to plain Windows ones doesn't help too...


Because your build is an Unicode one, and most of Windows API function names are just proxy (in fact macros) for their ANSI/Unicode counterparts depending on the build options.

Foobar plugins should be built to work on platforms with Unicode support (WinNT/2k/XP) and on those without (Win9x). If there are different versions of an API function in the Win32 API, you should either use the corresponding wrapper function from utf8api.dll, if there exists one, or write you own wrapper. In the latter case, use
Code: [Select]
if (IsUnicode())
{ /* Unicode version here */ }
else
{ /* ANSI version here */ }

instead of
Code: [Select]
#ifdef UNICODE
{ /* Unicode version here */ }
#else
{ /* ANSI version here */ }
#endif

as it is in the utf8api.dll code, as your plugin needs to contain both versions. That is, if you don't want to have separate versions for ANSI and Unicode.

Few questions

Reply #3
u* calls are from utf8api header, my plugin depends on the utf8api project.
(Foobar2000 installer installs correct version of the DLL for given platform)
API ANSI functions are *A, Wide *W.

UTF8API - uCreateWindowEx
ANSI API - CreateWindowExA
Wide API - CreateWindowExW

I suspect a compiler or SDK bug.
(additionally, my DateTime boxes are broken although I do handle calls correctly...
I have checked that with MSDN)
ruxvilti'a

Few questions

Reply #4
Quote
2. This code produces a window with title 'f'... Is there anything I can do to get whole title?

I'm not sure what's wrong here, it works for me. Do you have object files from compiles with previous versions of the SDK lying around? This could cause all kinds of weird errors...

 

Few questions

Reply #5
Weird - I'll archive my project (nearly done),
remove whole SDK, reinstall and then rebuild.
ruxvilti'a

Few questions

Reply #6
Reinstalling MSVC++ 6, then SP 5 didn't help, cleaning and updating SDK (0.7RC11 now) didn't help either.

I don't know what is wrong - if someone is interested, PM me with e-mail address
and I'll mail you the source and/or my binaries. (170 KiB total)
(LGPL anyway, but I have nowhere to post it yet)
ruxvilti'a

 
SimplePortal 1.0.0 RC1 © 2008-2019