![]() |
|
Is Mac OS X set_window_title() one of the cases that doesn't work? |
Runesabre
Member #7,573
August 2006
![]() |
Mac OS X set_window_title() doesn't appear to set the window title. Is that a known issue? _______________ |
Peter Hull
Member #1,136
March 2001
|
This code works OK for me, can you test and/or post code that doesn't work? (attached) #include <allegro.h> int main() { allegro_init(); install_keyboard(); set_gfx_mode(GFX_AUTODETECT_WINDOWED, 640, 480, 0,0); set_window_title("Matthew Leverton Ate My Hamster"); readkey(); } END_OF_MAIN() Pete
|
Runesabre
Member #7,573
August 2006
![]() |
I was calling set_window_title() before calling set_gfx_mode(). Moving the set_window_title() call after set_gfx_mode() works. Thanks Peter! _______________ |
Marcello
Member #1,860
January 2002
![]() |
Your poor hamster. Marcello |
Evert
Member #794
November 2000
![]() |
Quote: I was calling set_window_title() before calling set_gfx_mode(). Moving the set_window_title() call after set_gfx_mode() works.
The documentation doesn't specify an order for calling these in; should this be documented? |
Runesabre
Member #7,573
August 2006
![]() |
When I had set_window_title() called before set_gfx_mode(), Windows and Linux windows showed the proper window title while Mac did not. Personally, and if it's even possible, I prefer not to have an order requirement. Otherwise, a documentation note would be nice. Not a big deal either way, I'm just glad it works thanks to Peter's help. _______________ |
Evert
Member #794
November 2000
![]() |
Ok, I'll see if I can look into it before releasing 4.2.1 |
Peter Hull
Member #1,136
March 2001
|
It's already been thought of, apart from there's a bug. It works like this: The implementation of set_window_title copies the supplied title into the variable osx_window_title, and does the OS call to actually set the title if the window exists.
In set_gfx_mode, when the window is created, the call Still following me? So I propose an explicit check for this case, Index: src/macosx/system.m =================================================================== --- src/macosx/system.m (revision 7527) +++ src/macosx/system.m (working copy) @@ -563,7 +563,8 @@ { char tmp[ALLEGRO_MESSAGE_SIZE]; - _al_sane_strncpy(osx_window_title, title, ALLEGRO_MESSAGE_SIZE); + if (osx_window_title != title) + _al_sane_strncpy(osx_window_title, title, ALLEGRO_MESSAGE_SIZE); do_uconvert(title, U_CURRENT, tmp, U_UTF8, ALLEGRO_MESSAGE_SIZE); NSString *ns_title = [NSString stringWithUTF8String: tmp];
This is IMO the lowest impact solution, though probably not the neatest one. Pete ps. AFAIK, the behaviour of strncpy is supposed to be undefined if source and destination overlap (link) so the behaviour of _al_sane_strncpy seems quite reasonable in this case.
|
Evert
Member #794
November 2000
![]() |
Quote:
This is IMO the lowest impact solution, though probably not the neatest one. A single line comment describing what's going on might be nice, though I would probably change _al_sane_strncpy to leave the case source==destination alone. Quote: ps. AFAIK, the behaviour of strncpy is supposed to be undefined if source and destination overlap (link [opengroup.org]) so the behaviour of _al_sane_strncpy seems quite reasonable in this case. My manpage actually says something a bit stronger than that: Quote: The strings may not overlap
Still, it's called _al_sane_strncpy for a reason, right? |
|