Callback Question

[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

[tinman]

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)?

[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]