Hello again everyone, got some more details to provide about the SDK...
A question was asked earlier about the ReadHardData and DrawWave functions, specifically the "nReadLen" and "nDisLen" for the ReadHardData function and the "nSrcDataLen" and "nDisDataLen" for the DrawWave functions.
When I was implementing GUI controls for Vertical and Horizontal I noticed that my application wasn't behaving exactly the same way as the stock 6022BE software, more specifically the Horizontal scaling was way off.
I had a hunch as to what was causing it, but no idea how to solve it... It turns out the "Read Length" and "Display Length" properties were the culprit as I had used the default values provided in the "SDK" and "Manual" PDF file.
The problem is, these values are highly dependent on what timebase you are in, and there is no documentation on what values to use on which timebases, and there is only one example in the SDK and PDF of it's use, but not enough to figure out what the rest should be.
The first problem I had to tackle was what "Read Length" values to use for each of the 39 different timebases in the original software, and an earlier post in this thread got me close, but no cigar.
I ended up having to write a redirection dll for the HTDisplayDll.dll which is simply a DLL to use between the original software and the real HTDisplayDll.dll file so I can snoop around and see what is being passed into the DLL function calls. This process was VERY tedious and time consuming but I got it working and here is what I came up with.
Below is a snippet of code, an enum I use in my software to describe the 39 different timebases used by the two DLLs. The index values for each enum is in the same order as the Timebase drop-down list in the original software and not surprisingly the same values used by the DLLs. Each enum is grouped by "Read Length" (see samples comments) and followed by a comment which shows the "Display Length", "Horizontal Scaling" and "Vertical Scaling" "Zoom" arguments used in the DrawWave function, and it turned out they were all 1:1 ratio but never the less good to know.
//Time Division
enum THantekTimeDivision
{
//1016 samples
HTTimeDiv48MS_1NS=0, //960, 1, 1
HTTimeDiv48MS_2NS=1, //960, 1, 1
HTTimeDiv48MS_5NS=2, //960, 1, 1
HTTimeDiv48MS_10NS=3, //960, 1, 1
HTTimeDiv48MS_20NS=4, //960, 1, 1
HTTimeDiv48MS_50NS=5, //960, 1, 1
HTTimeDiv48MS_100NS=6, //960, 1, 1
HTTimeDiv48MS_200NS=7, //960, 1, 1
HTTimeDiv48MS_500NS=8, //960, 1, 1
HTTimeDiv48MS_1US=9, //960, 1, 1
HTTimeDiv48MS_2US=10, //960, 1, 1
//130048 samples
HTTimeDiv16MS_5US=11, //800, 1, 1
HTTimeDiv8MS_10US=12, //800, 1, 1
HTTimeDiv4MS_20US=13, //800. 1, 1
HTTimeDiv1MS_50US=14, //500, 1, 1
HTTimeDiv1MS_100US=15, //1000, 1, 1
HTTimeDiv1MS_200US=16, //2000, 1, 1
HTTimeDiv1MS_500US=17, //5000, 1, 1
HTTimeDiv1MS_1MS=18, //10000, 1, 1
HTTimeDiv1MS_2MS=19, //20000, 1, 1
//523264 samples
HTTimeDiv1MS_5MS=20, //50000, 1, 1
HTTimeDiv1MS_10MS=21, //100000, 1, 1
HTTimeDiv1MS_20MS=22, //200000, 1, 1
//1047552 samples
HTTimeDiv1MS_50MS=23, //500000, 1, 1
HTTimeDiv1MS_100MS=24, //1000000, 1, 1
HTTimeDiv500K_200MS=25,//1000000, 1, 1
HTTimeDiv200K_500MS=26,//1000000, 1, 1
HTTimeDiv100K_1S=27, //1000000, 1, 1
HTTimeDiv100K_2S=28, //2000000, 1, 1
HTTimeDiv100K_5S=29, //5000000, 1, 1
HTTimeDiv100K_10S=30, //10000000,1,1
HTTimeDiv100K_20S=31, //20000000,1,1
HTTimeDiv100K_50S=32, //50000000,1,1
HTTimeDiv100K_100S=33, //100000000,1,1
HTTimeDiv100K_200S=34, //200000000,1,1
HTTimeDiv100K_500S=35, //500000000,1,1
HTTimeDiv100K_1000S=36,//1000000000,1,1
HTTimeDiv100K_2000S=37,//2000000000,1,1
HTTimeDiv100K_5000S=38,//-1,1,1
};
As you can see, to scale the waveforms properly the "Display Length" is not the same as the "Read Length" and in some cases it's larger than the former.
Needless to say, my application now behaves exactly like the stock software and later on I'll post my DLL Hooking code that I used to reverse engineer the timebase argument convention.