Any idea of time frame for IBRemoteEvent to work?
NickBarrett opened this issue ยท 8 comments
We would really like the ability to listen for events being posted in our database.
We got quite excited when we saw the example code in events.md. Less excited when we realised the remote events methods in IBDatabase throw NotSupportedExceptions ๐ฌ๐
Is this feature on the horizon at all?
This is a feature we are considering adding
The Firebird code that this was based on also was not supported. I think the main reason is in all the InterBase API (and therefor the Fb API) the calling convention in windows is all stdcall except for the event API which is cdecl. The method they loaded and dereferenced the client library they were forced to make all calls stdcall because .NET does not support (using the way the did it) calling conventions other than stdcall.
Since I needed cdecl when loading the Mac or Linux client libraries I knew I could not load it the way they did so load it a different way and could support cdecl calling convention when needed. So I fixed up the API loading right, but the goal of the first release was to convert everything to InterBase, remove Fb specific items, fix up the loading code so it would run on platforms other than Windows, and add some IB features not found in Fb like the phase II Change View support. Events are not really straight forward. It includs needing to background thread stuff, setting up callbacks and other intricate stuff. In the end I will probably follow how I do it in IBX over in Delphi and C++Builder but right now we have not gone into this.
Note the Fb also has a managed version of the client library which basically embeds the client directly so it can run on other platforms because the calling convention of the client dll/so isn't used. While we discussed doing that, converting that was pretty much a no go as it would almost be written from scratch so we made the decision for now to require the client dll since I worked around the cdecl calling convention loading issue.
This is how the Fb code looks from what we based the IB code on. They had a plan, but I suspect due to the problem with the calling convention they never went further than a skeleton outline of work to be done.
{code}
public void CloseEventManager()
{
throw new NotSupportedException();
}
public void QueueEvents(RemoteEvent events)
{
throw new NotSupportedException();
}
public void CancelEvents(RemoteEvent events)
{
throw new NotSupportedException();
}
{code}
Sorry hit hte wrong button did not mean to close it
Thanks for the insight @jeffovercash
Added in 7.12.1. Currently does have a limitation to 15 events to listen for, I hope to lift that limitation in the next release.
Thanks for this @jeffovercash, much appreciated ๐
You are welcome. Sriram and I spent the better part of a week trying to figure out why the callback would suddenly stop on one block or the other when > 15 events. The block API is limited to 15 events per block so if you want to listen to 20 events, 15 go into a block in one thread and the next 5 will get a second thread. Both threads get the same callback. All memory in this area of the API is unique in that the IB client allocates and frees the memory so I had to be careful that the .NET GC kept its nose out of things.
What would happen is eventually the callback only would call one block or the other and stop calling the other block(s). Unfortunately, there are no debugging hooks into gds32 to figure out why. As time permits Sriram is going to put some hooks into it so it is not like throwing something over the wall and hoping there is someone to catch it. I'm leaning towards a memory overwrite somewhere but for the life of me, I could not find it. So the decision was to stop delaying it and put the artificial limit of 15 events per app. and then revisit it with some better debugging tools when Sriram gets a chance to add them.
Note the limit is enforced when assigning a List to the property (Events I think I can't recall off the top of my head right now), not if you call the property.Add().
There is a new events demo in the installer and should be pretty straightforward to see how this all works.
We've been using a small Delphi app that was listening for our events and then hitting an http endpoint in our .net app as a workaround. We're currently under the 15 event limit, so we'll start using this instead.
Thanks again to you and Sriram for all the hard work.