Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
GlobalAlloc Workspace?
Message
General information
Forum:
Visual FoxPro
Category:
Windows API functions
Miscellaneous
Thread ID:
00551490
Message ID:
00551674
Views:
19
>Hello Ed,
>
>Sorry about that. I have more than 1 typo in the document I sent in. Actually the code is bug free, but when I re-typed the sample code I missed a couple of spots. I don't have the code or DLL on this machine that I use to attach to UT.
>
>Anyway... I have commas in the DLL and the nsizeused is correct in the actual code.
>
>When you say you would DEBUG the DLL do you mean with C or some debugger like that or am I missing something with VFP?
>

If it's written in C/C++, you'd need to use the C debugger. The error does not occur on the VFP side.

>My other question is am I calling the Alloc() method correctly by freeing up 32000 bytes of memory? Here is what the whitepaper says, I am just making sure I am doing it correctly.
>

The Alloc() method sets aside a static block of memory, and returns a 32 bit pointer as an integer to the call. That integer serves as a pointer to the block of memory, so if your DLL expects to receive a pointer of some sort, then you'd declare the pointer as an INTEGER in the VFP DECLARE, and pass that value. The block remains allocated at the static address until you explicitly invoke the DeAlloc() method with that pointer value, or implicitly invoke it by destroying the object, which frees all remaining allocations.

>"The calling program must provide a workspace for DbServer.Dll. DbServer will do most of its processing & storing of data in this workspace. Currently, the work space must be at least 32k bytes (bigger won’t help). Visual Basic programs must provide this via the Windows memory allocation API. ‘C’ or Pascal programs may provide a pointer to a memory area. DbServer creates pointers within the work space, so if the memory is relocated, the work space must be re-initialized. This can happen with any call, and is signaled by an error return on the call. Error codes are listed in the “Return Error Codes” section of this document."
>

One issue - 32000 is not 32K; 32K is 32768. This may be significant. You can check the actual size of the block of RAM allocated to a given pointer by invoking the object's SizeOfBlock() method with the value of the pointer from the Alloc as follows:
SET PROC TO CLSHEAP ADDITIVE
oHeap = CREATEOBJ('Heap')
nPtr = oHeap.Alloc(32768)
? oHeap.SizeOfBlock(nPtr)
Alloc() sets aside a static block of memory and returns a pointer to it - the memory block referenced doesn't move or get reallocated unless DeAlloc() is invoked as mentioned above. The size might be larger than the requested size because of memory alignment issues, so you can use the SizeOfBlock() method to determine the actual amount of memory allocated.

>I can not get this thing to work for the life of me and I don't know why. Maybe I am missing something.

Does it work in other environments?
EMail: EdR@edrauh.com
"See, the sun is going down..."
"No, the horizon is moving up!"
- Firesign Theater


NT and Win2K FAQ .. cWashington WSH/ADSI/WMI site
MS WSH site ........... WSH FAQ Site
Wrox Press .............. Win32 Scripting Journal
eSolutions Services, LLC

The Surgeon General has determined that prolonged exposure to the Windows Script Host may be addictive to laboratory mice and codemonkeys
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform