callback function vrs virtual method in a class

[kryton9]

Charles, if you remember when we worked on the GLWindow class, we used callback functions for the render and input procedures.  I am completely rewriting that class, cGLWindow will have virtual methods render and input. The user of the class would derive their own class from cGLWindow and write their code in those virtual methods.

Which of these 2 ways should I select? Which would perform the best?

[Charles Pegge]

Hi Kent,

Callbacks are easier. Macros might be better still, depending on how much of cGLWindow you want to expose.

Stitching up WndProc in a class is not ideal. Usually the solutions are more complex than the classical code.

I think all the multiple couplings make the code quite difficult to debug. Anyway, I'll continue looking into this Window Architecture issue.

Charles

[Charles Pegge]

The code below is a modified Create method. It contains a wndproc link, supplying an object pointer so that WinProc can be redefined as a proper method with access to all the members of the class, instead of being a function with access restricted to static members only.

With this configuration, none of the class members have to be static, and new classes can be derived from cGLWindow without complication.

           'WndProc interface function
            '==========================
            '
            static thisObject, pwin
            '
            thisObject=@this
            pWin=@WindowProc#sys#sys#sys#sys
            '
            function WndProc( sys mhWnd, uMsg, wParam, lParam ) as sys callback
                return call pWin(thisObject,mhWnd, uMsg, wParam, lParam )
            end function
   

Code: OxygenBasic

1.  
2.         method Create( sys aWidth   =  800,
3.                        sys aHeight  =  600,
4.                        sys aBits    =   32,
5.                        sys aFullscreen = 0,
6.                        string aCaption = "Simple GLWindow",
7.                        sys aLeft = 0,
8.                        sys aTop  = 0,
9.                        sys aIcon = 0,
10.                        sys aMenu = 0 ) as sys
11.  
12.             mWidth     = aWidth
13.             mHeight    = aHeight
14.             mBPP       = aBits
15.             mLeft      = aLeft
16.             mTop       = aTop
17.             mCaption   = aCaption
18.             mClassName = "GLWindow"
19.  
20.             mWindowRect.left   = mLeft
21.             mWindowRect.right  = mWidth
22.             mWindowRect.top    = mTop
23.             mWindowRect.bottom = mHeight
24.  
25.             mFullScreen = aFullscreen
26.  
27.             mhInstance  = GetModuleHandle 0
28.             '
29.            'WndProc interface function
30.            '==========================
31.            '
32.            static thisObject, pwin
33.             '
34.            thisObject=@this
35.             pWin=@WindowProc#sys#sys#sys#sys
36.             '
37.            function WndProc( sys mhWnd, uMsg, wParam, lParam ) as sys callback
38.                 return call pWin(thisObject,mhWnd, uMsg, wParam, lParam )
39.             end function
40.             '
41.            WNDCLASS winClass
42.             winClass.style = CS_HREDRAW | CS_VREDRAW | CS_OWNDC
43.             winClass.lpfnWndProc   = @WndProc
44.             winClass.cbClsExtra    = 0
45.             winClass.cbWndExtra    = 0
46.             winClass.hInstance     = mhInstance
47.             winClass.hIcon         = LoadIcon NULL, IDI_WINLOGO
48.             winClass.hCursor       = LoadCursor NULL, IDC_ARROW
49.             winClass.hbrBackground = NULL
50.             winClass.lpszMenuName  = NULL
51.             winClass.lpszClassName = *mClassName
52.             if not RegisterClass @winClass then
53.                 'error
54.                MessageBox NULL, "RegisterClass", "ERROR", MB_OK
55.                 return 0
56.             end if
57.             Remake()
58.         end method
59.  

Charles

[kryton9]

Thanks for another way to do things example Charles.

What I want to do is make a window class for opengl that is very flexible. It can be:
1. simple glwindow with 1 viewport
2. simple glwindow with many viewports
3. 2 or more glwindows with 1 viewport each
4. 2 or more glwindows with many viewports each

The multiple windows would be able to be moved to different monitors.
So that the main monitor could be the actual game window fullscreen for instance. The second monitor could have other windows that could show maps for a level, statistics for the game, perhaps alternate views such as side, back, top and front for flight sims.

I was looking through the OOP examples folder and refreshed my memory on some of theoptions. I saw the interface examples, but couldn't I also just use virtual methods?

[Charles Pegge]

I'm not familiar with dual monitor technology. I presume there are some OpenGl functions to channel instructions to each video processor.

I think multiple child Opengl Windows will work on many but not all cards. Petr knows of problems with some ATI cards as I recall. I found it was okay to use a common hRC and simply switch the hDCs to build the scene frames in each child window. (Using NVidia)

Child Windows require somewhat different handling than the main window and they all have to be coordinated when resizing or stretching.

Not sure what what you mean by virtual methods, Kent. That could mean several things but having separate objects for each viewport or child window would make sense, and the basic architecture would be similar to what you have so far.

Charles

[kryton9]

It is fun working on this stuff and Oxygen is just amazing. Everyday it surprises me in how flexible it is. I don't how you put it together so quickly. I was trying to follow how you might have gone about it, but I kept running into the which came first the chicken or the egg. Its like where do you begin. I am amazed!

[Charles Pegge]

After a few adventures with machine code strings, and the Assembler, I started with a toy compiler which could just about manage a=b+c using integers. Then it was just a matter of extending its capabilities in all directions. Definitely not top-down design.

Charles

[Aurel]

Hi people..
I don't know how i miss this topic.
Charles what i need to compile this example ?
This might be solution for what i talk under GUI topic about elimination
of long code with DefWindowProc retrurn.
What you think?

PS.I don't like OOP but looks like good option...

Aurel

[kryton9]

Aurel, it can also be done without classes.

Perhaps it would be better if the forums were split into 2 parts. Flat Procedural Oxygen and OOP Oxygen?

In reviewing things that I forgot this passed month. Here is the difference between the two.

In flat coding you would do this:

MyFunction( IDofObject, WhatIWantToDoValues)

Here MyFunction would then depending on the IDofObject
Probably have a Switch statement to decide how to apply the function
for this type of object. Here for all new objects, the framework
code would need to be updated.


In OOP it is:

Object.MyFunction(WhatIWantToDoValues)

Here the Object would know what to do.
So code is self contatined and can be added without changing
old frame code for a new object type.

That is one of the key benefits of OOP. There are many more.

[Aurel]

Aurel, it can also be done without classes.

Hi Kent...
But how to do that, i am now totally confused
As you see from my posts i am searching for simple way to open window and
message processing without so much typing everytime :
Wndproc(sys h,m,w,l) as sys callback
...
...
select m
...
...
default
return Defwindowproc(h,m,w,l)

again..and again for each window.
Do you can provide example....?

[kryton9]

I will work on one tonight for you without OOP. Will post when finished and working.

updated:
I could not get it to work. Charles will have to look at it. I can't get the callback to work.
I tried @, & with it aInputProc =  and without, and no luck.

window.inc and test window.o2bas are the only 2 files you need to look at. The others are the includes working in oxygen from VB6 cleaned up files.

X

[Aurel]

Thank you Kent...
Yes you right ...not work because last parameter is not recognized.
I have think that this might be solution and i really like how you do this.
Kent ...i don't know if we can define last parameter as function
maybe on this way will work...

X

[kryton9]

I will keep working on it, but I think it needs Charles input to figure it out. I will try another idea I had today while out and about and see if I can get that to work.
Update: This is another approach. It compiles and runs, but the windows does not show up. It runs for very short time then terminates if you watch the processes in your system. Perhaps you can see what I am doing wrong. I am tired and will call it quits for now. I switched to using Charles
MinWin.inc to see if that would work. When I used my headers, it would give an error at CreateWindowEx. With the WinMin.inc it doesn't give any error.

X

[Aurel]

Thank you Kent..
I will try it right now...

Yes i agree ...this need Charles input of course..

[Aurel]

Unfortunately Kent don't work as all ours try-s.
It looks to me that only way might be Charles example with this pointer.
But i don't know how to compile & run this example...