Page 1 of 1
Callback Question
Posted: Thu May 22, 2003 8:23 pm
by dmoc
Because PB does not pass certain windows messages I want to have a standard callback routine as shown below, eventually in a pb "include" file of useful functions. The "If wi\cb<>0" part is so I can hook in a custom (ie, application specific) callback without rewriting the standard callback. "wi" is simply a structure I aim to keep windows setting in (such as the window position) and the "cb" field is set to to a function address with the usual parameters for Windows callbacks. I have two problems: first if you put a "Debug wi\cb" you'll see that even if it *is* zero the "If wi\cb<>0"
always evaluates to true! Second problem is (I think) due to the callback being executed as a seperate thread and trying to share variable/s.
So is there a bug with the "If"? Is this a daft idea? Is there a better way? Any suggestions appreciated.
Code: Select all
Procedure stdCB(wid, msg, wp, lp)
r = #PB_ProcessPureBasicEvents
Select msg
Case #WM_MOVE
wi\wx = WindowX()
wi\wy = WindowY()
EndSelect
If wi\cb<>0
r = CallFunctionFast(wi\cb, wid, msg, wp, lp)
EndIf
ProcedureReturn r
EndProcedure
Re: Callback Question
Posted: Thu May 22, 2003 11:15 pm
by tinman
dmoc wrote:pb "include" file of useful functions. The "If wi\cb<>0" part is so I can hook in a custom (ie, application specific) callback without rewriting the standard callback. "wi" is simply a structure I aim to keep windows setting in (such as
How have you given your standard callback access to your wi structure? I have done something similar to you, using a linked list with an element for each window, and I have no problems accessing it.
What does your structure look like (bearing in mind the structure array access problems in 3.62)?
Posted: Thu May 22, 2003 11:42 pm
by dmoc
Hi Tinman, thanks for the response,
How have you given your standard callback access to your wi structure?
As you see in the previous post. I'm using a dummy "custom" cb at the mo because of the problem with the "If" statement. Notice that the std cb proc accesses the "wi" variable, which simply contains several "long" variables for window pos, size, etc. In fact here it is below. Since last posting, I'm trying to get around the problem by running my main loop in a thread and using "Pause/ ResumeThread()" in the std callback (eventually my app will have to be multi-threaded anyway). It's just diverted me onto yet another problem though because ResumeThread() isn't doing it's job. I've also starting looking at Windows process/threads sync facilities for a solution but not too much because I'm ultimately aiming for a Linux based app. And now I've got distracted by the Reaction and Torque engines on
http://www.garagegames.com. Arrrrhhhh, recursion is eating me alive
Code: Select all
Structure WinInfoT
; Windowed
pi.l ; PB Window Identifier
pw.l ; PB Window Handle
wx.l ; Window X offset
wy.l ; Window Y offset
ww.l ; Window Width
wh.l ; Window Height
wt.s ; Window Title
wf.l ; Window Flags
; Screen
ps.l ; PB Screen Handle
sm.l ; Screen Mode (0: Windowed, 1: Fullscreen)
sx.l ; Screen X offset (windowed mode)
sy.l ; Screen Y offset (windowed mode)
sw.l ; Screen Width (fullscreen)
sh.l ; Screen Height (fullscreen)
sc.l ; Screen Colour Bits (fullscreen)
sd.l ; Screen Depth Bits (fullscreen)
st.s ; Screen Title
ws.l ; Window State (0: Opening, 1: Active, 2: Closing)
gh.l
gc.l
gr.l
cb.l ; CallBack Function (for application)
EndStructure
Global wi.WinInfoT
[/url]