>Ed,
>
>>I have a lot of code in place now that relies on the same functionality as CLSHEAP, and have already implemented classes like NETRESOURCE that offer different functionality than Christof's generic structure handling, so I haven't needed it for my own code. I'd like to see STRUCT use the same memory management API calls that CLSHEAP does and similar data conversion tricks, to eliminate the need for the external file that has to be distributed with STRUCT, but that isn't a major drawback - it's far less intrusive than an ActiveX control, requiring less 'attention' during installation.
>>
>>Neither STRUCT nor CLSHEAP handles low-level pointers and structures as easily or quickly as languages with native pointer support, and coding to use them would be relatively painful compared to C, at least for me. I'd go nuts if I had to rely on a call to a VCX to allocate each node of a directed graph and manipulate the pointers. In spite of agreeing with Marcus Egger, there are lots of places where life's too short to wait on VFP, and where you need to see more of the underlying metal and framework than VFP conveniently allows.
>
>Do you see any posibility to improve Pointer handling within VFP ?

Not without making significant changes to the internal memory representations and language capabilities in VFP. Look in the VFP docs to see how memvars are stored and manipulated within VFP to see some of the overhead. And then there's this tiny issue of VFP moving things around in memory as a result of garbage collection, with no native way of saying "You can't move this." Every time something gets moved, all the pointers to it, or things contained in it, have to be updated...and VFP doesn't know about them in and of itself.

VFP simply isn't well-suited to large-scale, detailed structure mainpulations; if I need C, I use C. I don't have thousands of API calls being made inside a VFP app, because it's costly. Look at how VFP represents things internally to see just how costly it is, and realize that every API call has to convert back and forth between VFP representations of things and their API equivalents, on top of needing to call an API every time I want to use memory where VFP can't move it around, and then move things back and forth between static memory blocks and VFP's variables.

>OIW in what way could the struct class be improved ? I for one, think that it might be handy if the struct class could import C/C++ header files to automaticly determine the internal structure, which is indeed one of the major drawbacks at the moment.

Aside from the revisions I've already noted to eliminate the need for additional distribution files, I think STRUCT accomplishes what it was intended to do very well - provide an easier mechanism for manipulating data structures not natively represented by VPF data types. It's not designed to be a replacement for writing things in another language where appropriate - it does make interfacing to standard C type DLLs requiring structures much easier.

If you want added functionality, Walter, write it. The mapping between a typedef and Christof's class representation of a structure isn't that different until complex structures start getting involved. It isn't a pressing need or overwhelming desire of mine to make changes to it, and it's not paying the mortgage or putting dinner on the table - you've got the problem, and the source code, so go fix it. That's generally what programmers do... :-)

You don't even need to change Christof's class - you just need to write something that creates a VFP class definition as source for inclusion in your application from a typedef. Might I suggest lex and yacc as very useful tools for this job?