Re: [fpc-pascal] Moving callbackfunctions to class

2011-01-01 Thread Paul Ishenin
31.12.2010 20:01, Darius Blaszyk wrote: On Dec 31, 2010, at 10:43 AM, Paul Ishenin wrote: 31.12.2010 7:53, Darius Blaszyk wrote: I installed 2.5.1 just to test if it was possible to use static class methods or not. Apparently not so it seems. It was a good try, but it failed. Thanks anyway f

Re: [fpc-pascal] Moving callbackfunctions to class

2010-12-31 Thread Darius Blaszyk
On Dec 31, 2010, at 2:23 PM, Reimar Grabowski wrote: > On Fri, 31 Dec 2010 14:03:27 +0100 > Darius Blaszyk wrote: > >> Unfortunately I need a platform independent method to handle this. So >> assembler is not really the way I want to go, unless it proves to be the >> only way. > > Now you kn

Re: [fpc-pascal] Moving callbackfunctions to class

2010-12-31 Thread Darius Blaszyk
On Dec 31, 2010, at 2:06 PM, Felipe Monteiro de Carvalho wrote: > On Fri, Dec 31, 2010 at 11:01 AM, Darius Blaszyk > wrote: >> Thanks for the tip Paul. Unfortunately it did not help. See for the results >> below. > > Using a correct type cast it should work. Which line brings the errors? Hi F

Re: [fpc-pascal] Moving callbackfunctions to class

2010-12-31 Thread Michael Van Canneyt
On Fri, 31 Dec 2010, Darius Blaszyk wrote: On Dec 31, 2010, at 10:43 AM, Paul Ishenin wrote: 31.12.2010 7:53, Darius Blaszyk wrote: I installed 2.5.1 just to test if it was possible to use static class methods or not. Apparently not so it seems. It was a good try, but it failed. Thanks a

Re: [fpc-pascal] Moving callbackfunctions to class

2010-12-31 Thread Reimar Grabowski
On Fri, 31 Dec 2010 14:03:27 +0100 Darius Blaszyk wrote: > Unfortunately I need a platform independent method to handle this. So > assembler is not really the way I want to go, unless it proves to be the only > way. Now you know why I called glut a major PITA and using platform dependent asse

Re: [fpc-pascal] Moving callbackfunctions to class

2010-12-31 Thread Felipe Monteiro de Carvalho
On Fri, Dec 31, 2010 at 11:01 AM, Darius Blaszyk wrote: > Thanks for the tip Paul. Unfortunately it did not help. See for the results > below. Using a correct type cast it should work. Which line brings the errors? -- Felipe Monteiro de Carvalho ___

Re: [fpc-pascal] Moving callbackfunctions to class

2010-12-31 Thread Darius Blaszyk
On Dec 31, 2010, at 10:43 AM, Paul Ishenin wrote: > 31.12.2010 7:53, Darius Blaszyk wrote: >> I installed 2.5.1 just to test if it was possible to use static class >> methods or not. Apparently not so it seems. It was a good try, but it >> failed. Thanks anyway for the help and explanation Jona

Re: [fpc-pascal] Moving callbackfunctions to class

2010-12-31 Thread Paul Ishenin
31.12.2010 7:53, Darius Blaszyk wrote: I installed 2.5.1 just to test if it was possible to use static class methods or not. Apparently not so it seems. It was a good try, but it failed. Thanks anyway for the help and explanation Jonas. Try {$mode delphi}. Best regards, Paul Ishenin _

Re: [fpc-pascal] Moving callbackfunctions to class

2010-12-30 Thread Darius Blaszyk
I installed 2.5.1 just to test if it was possible to use static class methods or not. Apparently not so it seems. It was a good try, but it failed. Thanks anyway for the help and explanation Jonas. It seems that GLut however offers a backdoor as was pointed out by honza. By using glutGetWindow,

Re: [fpc-pascal] Moving callbackfunctions to class

2010-12-30 Thread Jonas Maebe
On 30 Dec 2010, at 18:27, Darius Blaszyk wrote: > The intention is indeed to create a wrapper around the multiple callback > functions that GLut provides and additionally add some other methods and > properties. That is impossible since the callback does not offer any way to pass the self poi

Re: [fpc-pascal] Moving callbackfunctions to class

2010-12-30 Thread Darius Blaszyk
On Dec 30, 2010, at 6:09 PM, michael.vancann...@wisa.be wrote: > > > On Thu, 30 Dec 2010, Jonas Maebe wrote: > >> >> On 30 Dec 2010, at 17:34, Darius Blaszyk wrote: >> >>> As these functions are needed per window, I would like to encapsulate each >>> window in a class something like: >>> >

Re: [fpc-pascal] Moving callbackfunctions to class

2010-12-30 Thread michael . vancanneyt
On Thu, 30 Dec 2010, Jonas Maebe wrote: On 30 Dec 2010, at 17:34, Darius Blaszyk wrote: As these functions are needed per window, I would like to encapsulate each window in a class something like: TMyGLutWindow = class private procedure MyDisplayFunc; cdecl; public constructor Cre

Re: [fpc-pascal] Moving callbackfunctions to class

2010-12-30 Thread Jonas Maebe
On 30 Dec 2010, at 17:34, Darius Blaszyk wrote: > As these functions are needed per window, I would like to encapsulate each > window in a class something like: > > TMyGLutWindow = class > private >procedure MyDisplayFunc; cdecl; > public >constructor Create; > end; > > In the constr

Re: [fpc-pascal] Moving callbackfunctions to class

2010-12-30 Thread Honza
2010/12/30 Darius Blaszyk : > Though I understand the error, I do not know if there is a way to circumvent > this? I guess: In the callback you have to get the current window id using glutGetWindow, then dispatch the call to the right object instance using that id via some kind of mapping from wind

Re: [fpc-pascal] Moving callbackfunctions to class

2010-12-30 Thread Michael Van Canneyt
On Thu, 30 Dec 2010, Darius Blaszyk wrote: Hi, GLut defines callback functions, one of them is the display function, which is defined as: TGlutVoidCallback = procedure; cdecl; This is set by calling glutDisplayFunc(@MyDisplayFunc);  As these functions are needed per window, I would like t