Handle release for lhistoryhandle

[Mark Rockley]

Every time a call to listhistory is made, the handle lhistoryhandle is incremented. It is never actually set back to 0. Does anybody know how to fix this problem? Release history seems like it is supposed to do this but in Visual Basic .NET the handle just keeps incrementing. This is not a good thing.

[TGafford]

History data is stored internally as a table. The handle returned by the request history function is a pointer to a location within that table. This pointer is an integer value that is incremented upon each history request. For example:

lHistoryHandle = 0 // Initial value for the history handle

lHistoryHandle = some history request // return value is 1
lHistoryHandle = some history request // return value is 2
lHistoryHandle = some history request // return value is 3
lHistoryHandle = some history request // return value is 4
lHistoryHandle = some history request // return value is 5

The internal table would look something like this:

Handle Value--------------------Data

1--------------------------some history data
2--------------------------some history data
3--------------------------some history data
4--------------------------some history data
5--------------------------some history data

The lHistoryHandle is a local value-- local to the application. When you release a handle, it does not have an impact upon the current value to which lHistoryHandle is set. The release history function releases data associated with a handle value.

For example, if you release the history for handles 2 and 4 the internal table would like something like this:

Handle Value--------------------Data

1--------------------------some history data
2--------------------------no associated history data
3--------------------------some history data
4--------------------------no associated history data
5--------------------------some history data

The remaining handles (1, 3, 5) are all valid and have data associated with them. If you released the history for handle 5 and made another history request following that release, the value for the handle returned would be 6. The internal table continues to build sequentially, regardless of what is or isn't released.

There is no eSignal Desktop API function that indicates which handles have or have not been released. It is the responsibility of the application using the eSignal Desktop API to track:

1. the number of history handles it has

- and -

2. the handles that have been released.

One possible solution for doing so would be to employ a multidimensional array. The first element in such an array could represent that value of the handle, while the second could indicate if the handle were active (had associated data) or inactive (had been released).

Please note that like all sample applications, the sample application for the eSignal Desktop API is not meant to be representative of the perfect solution. The purpose of the sample application is to provide a quick overview of how one can integrate and use the eSignal Desktop API. The current sample provides one possible scenario. In this sample all history data is processed immediately upon request and none of the handles are released until the application exits. The FillHistory() function uses whatever is the current handle value. If your application will process multiple histories then it is important that some form of handle tracking be implemented.

I hope this has helped to clarify some points regarding the history handle, why it is incremented sequentially, and how the release history function relates to it.