SCO/RCO for all modules

[Senalaya]

After looking through the sources, I came to the idea, that it would be great if the SCO/RCO hook could be used by more modules than just the ODBC module.

I'd like to propose the following:
- include the scorcohook.* into the NWNXdll
- rename SQLSCO / SQLRCO to NWNXSCO / NWNXRCO.
- extend the CNWNXBase class with OnSCO() / OnRCO() methods.
- use the same syntax for the database name as for the stringvar name. (i.e. NWNX!ODBC or NWNX!ODBC!FETCHMODE, etc)
- the 'key' variable could then even be used for the SQL statement in case of ODBC.
- NWNXSCO / NWNXRCO then calls OnSCO() / OnRCO() for the module class. (about the same way as the Payload function does)

Discuss

Edit: Updated some of the ideas.

[dragonsong]

It would make very easy work for NWNX-Leto, at the least, so of course it has my vote.

I think for it to be of broad utility, though, the arguments in the events would have to be very generic - probably a pointer (memory) and an int (size); mind you, that's the opinion of a Delphi programmer thinking of porting the call over to a DLL in a completely foreign environment, and I could surely make do with something more structured. (My happy observation of NWNX thus far is very little attachment to MSVC libs, though.)
_________________
- dragonsong

[Papillon]

These are good ideas indeed. I want the dust to settle down a bit before making major changes to the codebase again, but I have no objections if someone else wants to try it out locally. When the current ODBC2 module is more stable, we can merge the changes back in.

dragonsong, what do you mean with "more structured" ?
_________________
Papillon

[dragonsong]

Well, whenever I have two classes talking to one another about some chunk of memory, I just have them pass a TMemoryStream back and forth, in Delphi. I think I've come to rely heavily on classes in the Delphi model, and my C has never been too strong. Using a pointer and an int almost seems "crude" to me, but I've become spoiled by a single-vendor environment.

I agree about letting the dust settle. Out of curiosity, I might take you up on a local build. (Though it's bound to be a patchwork build at best.)
_________________
- dragonsong

[JeroenB]

Heh.. using a memory stream and a pointer is almost similar to me . I just had a look in the documentation about that class. As far as I understand it, that stream allocates a part of the memory and you can store memory in there. In this case we can not do that as much objects are created by NWN. And storing those object everytime in a stream buffer costs to much time.

Only passing a pointer is a bit easier than first creating a stream object and then pass that on. We have written NWNX with speed and simplicity in mind.

[dragonsong]

Yes, and I think that's probably why Delphi still isn't considered quite as fast as C, since most Delphi programmers are wont to throw around objects, in the interest of simpler (I guess I wanted to use the word "more structured") code. But I have all respect for doing it the "hard" (fast, efficient) way, at the low level.
_________________
- dragonsong