Windowtitle() possible bug (latest testing release)

General FreeBASIC programming questions.
Sisophon2001
Posts: 1702
Joined: May 27, 2005 6:34
Location: Cambodia, Thailand, Lao, Ireland etc.
Contact:

Windowtitle() possible bug (latest testing release)

Postby Sisophon2001 » Feb 19, 2006 2:44

Hi:

I am still having trouble with the windowtitle function. It was causing crashes in my project last week, but I commented out the code when somebody else reported a bug with it, and a fix was uploaded. This morning I downloaded the latest testing release, and now there are no crashes, but the title is not being written correctly. When I use the command

Windowtitle "Testing"

I get the title

TestingBASIC_Projects\projects\Test\Test

Which is the exe path and name over written by the string. I do not get this error in all projects. I tested some of the sample code and it appeared to work correctly.

Are others seeing the same problem?

Garvan
cha0s
Site Admin
Posts: 5317
Joined: May 27, 2005 6:42
Location: Illinois
Contact:

Postby cha0s » Feb 19, 2006 2:48

maybe they were gonna make the windowtitle be the exepath + exename if null?? that would make sense. but its messed up i guess ;p
Sisophon2001
Posts: 1702
Joined: May 27, 2005 6:34
Location: Cambodia, Thailand, Lao, Ireland etc.
Contact:

Postby Sisophon2001 » Feb 19, 2006 6:35

@cha0s
Thanks for the confirmation that it was not only me.

@All
I cut my project down to nothing and the problem is still there.

Garvan

Code: Select all

option explicit
const XPixels = 800 '640
const YPixels = 600 '480
screenres XPixels, YPixels, 32
windowtitle "Testing"

   do
          sleep 5
   loop while inkey$ <> chr$(255, 107)

BastetFurry
Posts: 255
Joined: Jan 05, 2006 0:56

Postby BastetFurry » Feb 19, 2006 10:44

Works here...

Code: Select all

FreeBASIC Compiler - Version 0.15 for linux (target:linux)
Copyright (C) 2004-2005 Andre Victor T. Vicentini (av1ctor@yahoo.com.br)

Tested with gnome2.
Are you using Windows?
Ill test 0.16 in a moment.
BastetFurry
Posts: 255
Joined: Jan 05, 2006 0:56

Postby BastetFurry » Feb 19, 2006 10:49

Behaviour with 0.16:
First i have the AppName in the title bar (added a do:loop until inkey <> "")
Then i have Testingastetfurry/temp/wintitle.
Ill play a bit with that.... more later
axipher
Posts: 891
Joined: Dec 27, 2005 16:37
Location: Sudbury,Ontario
Contact:

Postby axipher » Feb 19, 2006 19:24

I just did A mini test and I conclude that the console, the non-gfx one is not affected by windowtitle, but only the gfx one is.

Here is the FB manual insertion of windowtitle:

This statement is useful to change the program window title. The new title set will become active immediately if the program already runs in windowed mode, otherwise will become the new title for any window produced by subsequent calls to the SCREEN (GRAPHICS) statement. If you never call this function before setting a new windowed mode via SCREEN (GRAPHICS), the program window will have your executable file name without extension as title by default.
This command has no effect for consoles.


Hope that clears it up. But windowtitle should affect the console too, that would be much better.
Antoni
Posts: 1393
Joined: May 27, 2005 15:40
Location: Barcelona, Spain

Postby Antoni » Feb 19, 2006 20:06

Windowtitle works only for graphics screens, don't know why a console title can't be changed.

It looks like windowtitle has presently two more bugs:
-It does not erase previous window title
-It stalls the program if used inside a screenlock/screenunlock pair

I noticed too the complete path in the default window title
V0.16 testing feb-18 Win32
voodooattack
Posts: 605
Joined: Feb 18, 2006 13:30
Location: Alexandria / Egypt
Contact:

Postby voodooattack » Feb 20, 2006 12:07

you can always set the console title manually on windows:

Code: Select all

#include "windows.bi"

CALL SetConsoleTitle ("Hello World!")

sleep


But i have no idea how'd you do that on linux :-/
axipher
Posts: 891
Joined: Dec 27, 2005 16:37
Location: Sudbury,Ontario
Contact:

Postby axipher » Feb 20, 2006 18:07

That's the problem, all the programs I make, I try to keep them cross-platform so using API is shunned by me.
lillo
Site Admin
Posts: 447
Joined: May 27, 2005 8:00
Location: Rome, Italy
Contact:

Postby lillo » Feb 20, 2006 21:08

It looks like windowtitle has presently two more bugs:
-It does not erase previous window title
-It stalls the program if used inside a screenlock/screenunlock pair


I just fixed the first problem in CVS (note to self: never forget to test your patches before applying them...)
About the second issue, I can't reproduce. In fact, WINDOWTITLE and SCREENLOCK/UNLOCK are completely unrelated...
Antoni
Posts: 1393
Joined: May 27, 2005 15:40
Location: Barcelona, Spain

Postby Antoni » Feb 20, 2006 21:44

lillo wrote:
About the second issue, I can't reproduce. In fact, WINDOWTITLE and SCREENLOCK/UNLOCK are completely unrelated...


This code freezes and never changes the window title or prints "Finished"

Code: Select all

screen 12
screenlock
windowtitle "hello"
screenunlock
print "Finished"
sleep


I have v0.16 last testing version for Win32. Windows 2000SP4, Directx 9.0c and a NVidia Riva TNT2 Card with 16 Mb RAM
v1ctor
Site Admin
Posts: 3798
Joined: May 27, 2005 8:08
Location: SP / Bra[s]il
Contact:

Postby v1ctor » Feb 21, 2006 1:03

I think only direct access to the frame buffer should be done between the ScreenLock and ScreenUnlock calls, the window thread will acquire the mutex too and won't process any messages, Windows should just put the change-window-title-whatever message in the queue and return, but that's not happening.

The doc pages for Screenlock/unlock can be updated, they only say you shouldn't call any draw primitives functions while the screen is locked.
Antoni
Posts: 1393
Joined: May 27, 2005 15:40
Location: Barcelona, Spain

Postby Antoni » Feb 21, 2006 8:07

v1ctor wrote:The doc pages for Screenlock/unlock can be updated, they only say you shouldn't call any draw primitives functions while the screen is locked.

And that is not true anymore, I remember lillo changed it...

Btw, another weird thing happened to me in a PC with W98 when I issued a sleep at the end of a program just after a screenunlock. The program got to the sleep but the last redraw freezed at mid-window. Probably the problem is related with what v1c explains.
The PC had a v0.15 testing version of QB, the behavior should not have changed as lillo did'nt update gfxlib during the last fall. I have no access to that PC during the week
cha0s
Site Admin
Posts: 5317
Joined: May 27, 2005 6:42
Location: Illinois
Contact:

Postby cha0s » Feb 21, 2006 9:11

Antoni wrote:
v1ctor wrote:The doc pages for Screenlock/unlock can be updated, they only say you shouldn't call any draw primitives functions while the screen is locked.

And that is not true anymore, I remember lillo changed it...


v1c said you shouldn't do it, not that you can't do it.
lillo
Site Admin
Posts: 447
Joined: May 27, 2005 8:00
Location: Rome, Italy
Contact:

Postby lillo » Feb 21, 2006 20:33

Ok, the issue was present on Win32 because of the SetWindowText() call issued by gfxlib when calling WINDOWTITLE eventually handed a message to the window messages thread, and probably blocked until getting a reply. But the messages thread was locked by SCREENLOCK so the call blocked indefinitely... Fixed in CVS.

Return to “General”

Who is online

Users browsing this forum: No registered users and 1 guest