Newbie: Callbacks and passing by reference

> I'm trying to call a function from a callback which returns two parameters
> passed by reference .... and it doesn't work ;-(
>
> I'm using the following code:
>
> | lib processedFiles processedBytes callback |
>     "lib gets initialized here"
>     processedFiles := 0.
>     processedBytes := 0.
> callback := ExternalCallback block: [
> lib zGetRunTimeInfoProcessedFiles: processedFiles
> asExternalAddress
> processedBytes: processedBytes asExternalAddress.
> Transcript show: processedFiles displayString , ' Files and ' ,
> processedBytes displayString , 'Bytes';cr.
> ] argumentTypes: ''.
> lib zCompressFilesTempDir: 'c:\temp\' password: '' compressionMethod:
> 3 resetArchiveAttribute: true spanSize: -1 comment: '' rtInfoFunc:

>I'm not sure what you are trying to do, but I think you might be getting
>confused between the old ExternalMethod style of callbacks and the
>preferred BlockCallbacks. If using the latter you don't need an external
>method definition. The callback arguments are passed to the block as its
>arguments, and you will need to specify the argument types (e.g. by
>passing 'sdword* sdword*' as the second argument to ExternalCallback
>class>>block:argumentTypes:, though I don't quite see why they would be
>pointers in this case since it looks like they are used for passing
>information in). I would suggest looking at the uses in the image, or at
>the Education Centre, which has comprehensive documentation on external
>interfacing.
>
>Regards
>
>Blair
>
>

> Udo,
>
> I may be missing the point here but have you tried using DWORDs
>
> processedFiles := DWORD new.
> processesBytes := DWORD new.
> self
>     zGetRunTimeInfoProcessedFiles: processedFiles
>     processedBytes: processedBytes.
> "you might need a #asParameter or #yourAddress after the two arguments?"
>
> processedFiles value inspect.
> processedBytes value inspect
>
> Just a thought
>
> Ian
>
>
>
>
>
>

> Ian,
>
> your thought was right. Using DWORDs with #yourAddress for passing solves
> the problem.
>
> Now I can start implementing the high level interface for the Big Zip
> Library.
>
> Thanks for your support,
>
> Udo

> "Udo Schneider" <[hidden email]> schrieb im Newsbeitrag
> news:Xns90C55AA084BFFUdoSchneiderhomeaddr@130.133.1.4...
> > Ian,
> >
> > your thought was right. Using DWORDs with #yourAddress for passing solves
> > the problem.
> >
> > Now I can start implementing the high level interface for the Big Zip
> > Library.
> >
> > Thanks for your support,
> >
> > Udo
>
> Udo,
>
> should you be successful, what I hope, please let me know.
> I had some major problems implementing Zlib in Dolphin recently.
> I used the original Zlib.dll, which can be assumed to be error free.
> But with WriteStreams there was a misterious fault, I could not track down,
> because somewhere the stream "dissapeared in the VM :-) ".
> In short: Small files ~100 lines are okay, larger give extra output. Nobody
> knows why. Bill Schwab an I tried to find out...
> While reading via ReadStream generally works, I had to workaround
> the writing problem by circumventing  WriteStream. I simply subclassed
> <File> with <TextFile> and introduced a TextFile>>writeLine: method.
> Interestingly that works well, beeing <GZipFile> a subclass of <TextFile>.
> Binary writes are no problem at all.
>
> Regards and good luck
> Ingo

> there is no Directory class in Dolphin. The functionality can be found in
> File....
>
> Udo
>
>
> Ingo Blank wrote:
>
> > "Udo Schneider" <[hidden email]> schrieb im Newsbeitrag
> > news:Xns90C55AA084BFFUdoSchneiderhomeaddr@130.133.1.4...
> > > Ian,
> > >
> > > your thought was right. Using DWORDs with #yourAddress for passing

> > > the problem.
> > >
> > > Now I can start implementing the high level interface for the Big Zip
> > > Library.
> > >
> > > Thanks for your support,
> > >
> > > Udo
> >
> > Udo,
> >
> > should you be successful, what I hope, please let me know.
> > I had some major problems implementing Zlib in Dolphin recently.
> > I used the original Zlib.dll, which can be assumed to be error free.
> > But with WriteStreams there was a misterious fault, I could not track

> Udo,
>
> would you like to look into my sources ?
>
> Ingo
>
> "Udo Schneider" <[hidden email]> schrieb im Newsbeitrag
> news:[hidden email]...
> > Ingo,
> >
> > I have no idea right now in which way I should implement the high level
> > functions. The problem with the lib is the fact the the lib only knows
> files.
> > You can define the zip file and then compress/decompress other files into
> it.
> > Maybe I should subclass File. Subclassing Stream makes no sense.
> >
> > I think implementing as some kind of "Directory" makes sense.
> Unfortunately
> > there is no Directory class in Dolphin. The functionality can be found in
> > File....
> >
> > Udo
> >
> >
> > Ingo Blank wrote:
> >
> > > "Udo Schneider" <[hidden email]> schrieb im Newsbeitrag
> > > news:Xns90C55AA084BFFUdoSchneiderhomeaddr@130.133.1.4...
> > > > Ian,
> > > >
> > > > your thought was right. Using DWORDs with #yourAddress for passing
> solves
> > > > the problem.
> > > >
> > > > Now I can start implementing the high level interface for the Big Zip
> > > > Library.
> > > >
> > > > Thanks for your support,
> > > >
> > > > Udo
> > >
> > > Udo,
> > >
> > > should you be successful, what I hope, please let me know.
> > > I had some major problems implementing Zlib in Dolphin recently.
> > > I used the original Zlib.dll, which can be assumed to be error free.
> > > But with WriteStreams there was a misterious fault, I could not track
> down,
> > > because somewhere the stream "dissapeared in the VM :-) ".
> > > In short: Small files ~100 lines are okay, larger give extra output.
> Nobody
> > > knows why. Bill Schwab an I tried to find out...
> > > While reading via ReadStream generally works, I had to workaround
> > > the writing problem by circumventing  WriteStream. I simply subclassed
> > > <File> with <TextFile> and introduced a TextFile>>writeLine: method.
> > > Interestingly that works well, beeing <GZipFile> a subclass of
> <TextFile>.
> > > Binary writes are no problem at all.
> > >
> > > Regards and good luck
> > > Ingo
> >

> Udo
>
> You wrote in message
> news:Xns90C55AA084BFFUdoSchneiderhomeaddr@130.133.1.4...
> > Ian,
> >
> > your thought was right. Using DWORDs with #yourAddress for passing solves
> > the problem.
> >...
>
> I think you only need the #yourAddress because you have defined the two
> parameters as lppvoid, they should be sdword* (or lpvoid). lppvoid is for
> double indirections (pointer to pointer). Also for signed integers you
> should really use SDWORD.
>
> Regards
>
> Blair