Help - Search - Members - Calendar
Full Version: Loading/using a DLL?
AC Tools Everything Macro > General Discussion > C++/Delphi/VB Development
Starhawk
I've been writing a DLL in VB, that is just a series of classes (I have written FFXI Memory grabbing routines, and put it all into a more managable class).. Is there any way I can access this DLL from ACtools, or possibly any way to add such a feature to the program?

Some examples of use:


FFXI.Update ' This updates all the values

FFXI.Target.TargetName ' returns the target's name


If something like this was usable, I'd be willing to donate it the cause. smile.gif
Ipa
The ScriptBridge component that I wrote in VB6 accomplishes this, except you'd need to add an executable on the other side of the bridge that loads your DLL.

Then you could munge some of the ACTool Companion calls to force parameters through to your EXE/DLL combo and your EXE would put results into {PluginResult} for use by the ACTool macro.
Starhawk
ok. After a lot of banging my head into the wall, I've decided to finally post here...

I've gotten this working for the most part. I'm using GetAttrib (variable name) as my method of calling values.

It dawned on me that I could also write the values for _X, _Y, _Z, etc. directly..

My main problem, is I can't seem to get PAST any delphi Dwords. I've tried making them VB Longs, as well as other formats, and tried to bypass them by making them byte arrays of almost every conceivable length!

If you can offer any assistance in how I would CORRECTLY read dwords in the type defintion listed in the scriptbridge source, I would GREATLY appreciate it!!

--Turz
Triane
Note that this is pure speculation, but is it a HOB/LOB issue? (High-order-byte/Low-order-byte)?

What I mean is, if Delphi for whatever reason, stores a DWORD in a reverse bit-order, I can see how that would cause a problem where even having the right number of bits would still produce erroneous results....

Hehe -- although, like I said, I'm just spitballing here..

-Triane
Starhawk
actually, best I couled fine, the value was shifted 1 bit. No matter what I did, it contuned to be 1 bit off...

I have a feeling its something to do with the exact way that vb stores the value.

Any chance you know how to reconstruct the value from a byte aray?

I have a fairly decent left/right shift routine, I'll have to do some experimenting...
Triane
Hmm, is it because in Pascal a DWORD is an unsigned integer? (so the last bit instead of indicating a negative, is actually a value?)

-Triane
Starhawk
Not quite sure what it is, but I've figured out a way around it..

Any Dword or Longword variables, I declare as string * 4 (the most generic declare you can get to fill up exactly 4 bytes)

Then I do a little creative work..

here's an example for the number 100

dword = Chr$(100) & Chr$(0) & Chr$(0) & Chr$(0)

I'm working on writing a function that will more neatly convert values for me, so that it will actually be USEFUL, but this is what I have to go thru to cram 100 into a pascal dword equivalent. smile.gif

Starhawk
Ugh. Maybe I just don't understand what I'm doing, but this is getting messy quick. I've now gotten about half of the "useful" (When I say that, i mean related to FFXI) variables mapped, however I'm up to the Delphi Single data type, and I'll have to spend some time figuring out how to write that the way I expect to see it....
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2010 Invision Power Services, Inc.