Hi,
I want to use some Win32 API functions to make my app a bit more windoze friendly, most notably to place temporary files in the correct location (GetTempPath) and to find out where the user's home directory is (haven't found that one yet ;)).
My knowledge of FFI is as big as that of Win32, i.e. almost completely absent. I haven't seen an example that uses the 'LPTSTR' (char **?) argument type, so I'm a bit at a loss as how to do this - could somebody help me here?
TIA,
Cees
Not trying to point you another direction, but .NET wraps this up nicely and with our Squeak.NET package your code would look like:
DotNet Path getTempPath "-> to get the temp path" DotNet Environment getFolderPath: DotNet SpecialFolder Personal "-> to get the user home directory"
I know this is *not* via FFI and I don't play much in that arena so I couldn't provide much guidance as to how to map char**.
So if I really wanted to do it via FFI -- well, I wouldn't. I'd just use the .NET interop package.
Regards,
John
On Tue, 25 Jan 2005 23:40:02 +0100, Cees de Groot cg@cdegroot.com wrote:
Hi,
I want to use some Win32 API functions to make my app a bit more windoze friendly, most notably to place temporary files in the correct location (GetTempPath) and to find out where the user's home directory is (haven't found that one yet ;)).
My knowledge of FFI is as big as that of Win32, i.e. almost completely absent. I haven't seen an example that uses the 'LPTSTR' (char **?) argument type, so I'm a bit at a loss as how to do this - could somebody help me here?
TIA,
Cees
On Tue, 25 Jan 2005 18:32:59 -0500, John Pierce john.raymond.pierce@gmail.com wrote:
Not trying to point you another direction, but .NET wraps this up nicely and with our Squeak.NET package your code would look like:
I want to keep the installer small. Which sort of rules out adding .NET runtime for the handful of simple functions I'm going to need - I rather write a plugin if FFI can't handle this...
On Tuesday 25 January 2005 2:40 pm, Cees de Groot wrote:
I want to use some Win32 API functions to make my app a bit more windoze friendly, most notably to place temporary files in the correct location (GetTempPath) and to find out where the user's home directory is (haven't found that one yet ;)).
My knowledge of FFI is as big as that of Win32, i.e. almost completely absent. I haven't seen an example that uses the 'LPTSTR' (char **?) argument type, so I'm a bit at a loss as how to do this - could somebody help me here?
Actually, LPTSTR is just a pointer to a TSTR. But a TSTR is either a 16-bit or an 8-bit character, depending on a macro setting. And so you'd either call GetTempPathA or GetTempPathW, depending on character size (8 bit or 16 bit, respectively)
So, assuming that 8-bit chars are OK for you, it'd be
GetTempPathA(DWORD nBufferLength, LPCTSTR lpBuffer );
Andreas explains how to return strings: http://lists.squeakfoundation.org/pipermail/squeak-dev/2002-April/038604.htm...
Some information about pointer-to-pointer usage: http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-September/067362...
On Tue, 25 Jan 2005 18:39:08 -0800, Ned Konz ned@squeakland.org wrote:
GetTempPathA(DWORD nBufferLength, LPCTSTR lpBuffer );
Yup. Found out that much ;). Module seems to be 'kernel32.dll', not?
Andreas explains how to return strings: http://lists.squeakfoundation.org/pipermail/squeak-dev/2002-April/038604.htm...
Some information about pointer-to-pointer usage: http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-September/067362...
Just the stuff I was looking for - thanks!
On Tue, 25 Jan 2005 18:39:08 -0800, Ned Konz ned@squeakland.org wrote:
GetTempPathA(DWORD nBufferLength, LPCTSTR lpBuffer );
Which would mean
apiGetTempPathBufferSize: aNumber inTo: aString <apicall: long 'GetTempPathA' (long char *) module: 'kernel32.dll'> ^self externalCallFailed
Should be sort of ok, not?
I get the error message 'Only ExternalFunctions can be called' when I try this - does this means that my arguments are messed up or that this <apicall: > thingie is not correct?
(recalling the time that I first tried JNI. Or the VW native interface. Or ...)
Am 26.01.2005 um 22:29 schrieb Cees de Groot:
On Tue, 25 Jan 2005 18:39:08 -0800, Ned Konz ned@squeakland.org wrote:
GetTempPathA(DWORD nBufferLength, LPCTSTR lpBuffer );
Which would mean
apiGetTempPathBufferSize: aNumber inTo: aString <apicall: long 'GetTempPathA' (long char *) module: 'kernel32.dll'> ^self externalCallFailed
Should be sort of ok, not?
Hmm, I'm not sure if you can use a String as buffer here - if I am not mistaken you can only pass in ByteArrays and ExternalAddresses where a pointer is required.
I get the error message 'Only ExternalFunctions can be called' when I try this - does this means that my arguments are messed up or that this <apicall: > thingie is not correct?
Not sure about that ...
- Bert -
Folks -
There is a problem with the FileList in Squeak 3.9 which I consider to be serious. My reason for writing this is not to complain, but just to make sure that *in addition* to welcoming extended character sets into Squeak, we *remain committed* to the value of simplicity and generality in the FileList.
From the beginning, the FileList has been a vital tool, and I cannot remember when a flaw in it would be tolerated for more than a few hours. It is the one way for a quantum mechanic to examine exactly what is in a file (normal as well as hex views), to patch broken files, to copy textual or binary data from one place to another, and so on. The FileList worked *identically* on local files as well as remote files. Moreover it worked identically on Windows, Mac, and Unix and, for a Squeaker in a foreign land, it was often the *only* way to get something done simply and accurately.
Beginning with 3.8, most of this rock-solid simplicity seems to be broken. For instance, I just tried to copy the contents of one file to another by the usual select-all / copy / select-all / paste sequence, and it did not work. This has *always* worked on every file system, local or remote and, if it's broken it is often not clear what tool will do the job, and how to get at it.
As another example, selection is broken in the FileList in the presence of binary data, making it nearly impossible to do some patches. I think this is just a problem of character widths in the font being used, but I'm not sure.
This is just a plea that we not give up on the FileList as a rock-solid tool, while embracing the importance of international character support. The FileList never was a document editor; it never displayed RTF, and it doesn't need to display international characters. If we want it to do that, then it must be as an option that leaves inviolate the ability to perform reliable file surgery when necessary.
Besides just raising the issue I'm willing to help out -- anyone working on this is welcome to write me to pursue the matter farther.
- Dan
Hi all!
Dan Ingalls Dan@SqueakLand.org wrote:
Folks -
There is a problem with the FileList in Squeak 3.9 which I consider to be serious. My reason for writing this is not to complain, but just to make sure that *in addition* to welcoming extended character sets into Squeak, we *remain committed* to the value of simplicity and generality in the FileList.
I agree.
[SNIP]
This is just a plea that we not give up on the FileList as a rock-solid tool, while embracing the importance of international character support. The FileList never was a document editor; it never displayed RTF, and it doesn't need to display international characters. If we want it to do that, then it must be as an option that leaves inviolate the ability to perform reliable file surgery when necessary. Besides just raising the issue I'm willing to help out -- anyone working on this is welcome to write me to pursue the matter farther.
- Dan
I don't know if anyone is looking into this - but I just wanted to voice my agreement that one of the virtues of Filelist has always been that it "just shows the damn bytes", so to speak.
regards, Göran
Dan,
Beginning with 3.8, most of this rock-solid simplicity seems to be broken. For instance, I just tried to copy the contents of one file to another by the usual select-all / copy / select-all / paste sequence, and it did not work. This has *always* worked on every file system, local or remote and, if it's broken it is often not clear what tool will do the job, and how to get at it.
Copying and pasting sounds like a good one.
As another example, selection is broken in the FileList in the presence of binary data, making it nearly impossible to do some patches. I think this is just a problem of character widths in the font being used, but I'm not sure.
This is just a plea that we not give up on the FileList as a rock-solid tool, while embracing the importance of international character support. The FileList never was a document editor; it never displayed RTF, and it doesn't need to display international characters. If we want it to do that, then it must be as an option that leaves inviolate the ability to perform reliable file surgery when necessary.
The truth is that that aspect of filelist isn't working for anyone. I have to say that I've never done with the text pane of FileList seriously. It'd be the time to cut the loose ends.
Besides just raising the issue I'm willing to help out -- anyone working on this is welcome to write me to pursue the matter farther.
Thank you!
-- Yoshiki
On Thu, 27 Jan 2005 00:35:27 +0100, Bert Freudenberg bert@impara.de wrote:
Hmm, I'm not sure if you can use a String as buffer here - if I am not mistaken you can only pass in ByteArrays and ExternalAddresses where a pointer is required.
Yup. In the meantime I found out how to pass long* and byte* arguments ;).
I get the error message 'Only ExternalFunctions can be called' when I try this - does this means that my arguments are messed up or that this <apicall: > thingie is not correct?
Not sure about that ...
Funny - it happens every time when I want to test stuff around it with the debugger. When I just run through it, it finds and executes the call...
Am 27.01.2005 um 16:08 schrieb Cees de Groot:
On Thu, 27 Jan 2005 00:35:27 +0100, Bert Freudenberg bert@impara.de wrote:
Hmm, I'm not sure if you can use a String as buffer here - if I am not mistaken you can only pass in ByteArrays and ExternalAddresses where a pointer is required.
Yup. In the meantime I found out how to pass long* and byte* arguments ;).
I get the error message 'Only ExternalFunctions can be called' when I try this - does this means that my arguments are messed up or that this <apicall: > thingie is not correct?
Not sure about that ...
Funny - it happens every time when I want to test stuff around it with the debugger. When I just run through it, it finds and executes the call...
Not funny at all - is this reproducable? It would mean the simulator is broken. I'm pretty sure that didn't happen to me before (but then, I'm usually not developing on Windows).
- Bert -
On Thu, 27 Jan 2005 23:38:49 +0100, Bert Freudenberg bert@impara.de wrote:
Not funny at all - is this reproducable? It would mean the simulator is broken. I'm pretty sure that didn't happen to me before (but then, I'm usually not developing on Windows).
Yup, seems to be reproducable. I just stepped over "Win32Window getFocus messageBox: 'Hello World'" (a snippet in a method comment in the win32 ff demo code) and it resulted in an error when stepping over #getFocus.
I must say that I have a funny VM - Rob Gayvert's wxSqueak VM. It's late and I'm too tired to install a clean Squeak; but I think it shouldn't matter, wxSqueak just adds some primitives and two or three patches around (I think) event handling.
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Cees de Groot -
Dan Ingalls -
goran.krampe＠bluefish.se -
John Pierce -
Ned Konz -
Yoshiki Ohshima