SDK for AppForge?

[GPSfan]

Is there an Ique SDK for AppForge? Can I access the GPS functionality from Visual Basic with AppForge?

[rwsmith123]

No.

Probably. You can look at the header files and documentation from the iQue SDK to see what SYS_TRAP is sent for each api call and what data is returned.

[Bokkie]

Originally posted by GPSfan
Is there an Ique SDK for AppForge? Can I access the GPS functionality from Visual Basic with AppForge?


Ha! Ha! Ha! Screeeeeech! Ho! Guffaw! Hysterical shrieking...


GPSfan, my man, I don't know what planet you live on, but if you ever open up ecotourism adventures and excursions then please let me know. I'll book the first ticket. :D

Seriously. I have been down that road and it is not pretty. The relationship between AppForge and the iQue is not at all straightforward. It looks a bit like a chicken with red lipstick, not a pretty bird.

All external interaction with the iQue (read Palm) has to be performed using a Fuser. The problem though, is that GPS events are notified using message loops. For example, you close the antenna and a native application knows about it. The problem though is that you cannot pass the message handler as a callback to the AppForge app. In this respect, you will find GPS management a problem. Most Fuser functions are driven through a single parameter and use a scalar return value, hence you might experience problems passing structures in and out. It should be possible, just be aware that you might have trouble.

So, we have an impasse. Your AppForge app wants to know when a GPS event is raised but it cannot assign a callback function. This is I think, simply a restriction of the Fuser. Others more knowledgeable than me will correct me if I'm hopelessly floundering in a cow pat. Is there a solution?

Yes! Except now we have moved from chickens with red lispstick to turkeys with foundation cream and mascara. Still one helluva ugly bird. What you can do is use one of the ingots to set up a TCP socket on 127.0.0.1 (aka there's no place like home) and use one of the higher port numbers. Port numbers 0-1023 should be avoided so use one in the stratosphere as it were. Connect to that port. So far so good. You will need an application on the iQue, but this time you will need a C-based app that can handle the message notification from the iQue GPS library which presumably you will have spinning on a timed loop, say every second or so. When the message is notified, your C-based application can then hook up as a client on the same IP address and port, and once done, you have effectively created a sort of pseudo conduit between you and the C-based application, and this will bypass the intrinsic restrictions of the Fuser. It will also be faster than a Fuser. Fuser's are easy to code and there are examples in AppForge but they were not designed I think, for realtime processing.

Hope this helps. If it does you heard it first on Radio Bokkie. If it does not, you heard it first on Curious Cat Cable.

:D

[rwsmith123]

You don't have to be event driven from the gps. You can simply poll once a second.

I've never used AppForge. Isn't there a way you can call extern "C" functions from it? If so then it shouldn't be too hard. If not is there a way to do system traps or pace native calls?

[Bokkie]

Originally posted by rwsmith123
You don't have to be event driven from the gps. You can simply poll once a second.

I've never used AppForge. Isn't there a way you can call extern "C" functions from it? If so then it shouldn't be too hard. If not is there a way to do system traps or pace native calls?

Not as far as I know. All the material I looked at interfaced exclusively to external libraries using Fusers. I agree, Rich, about not requiring the message loop. I was wearing the Palm hat from the perspective of the iQue GPS. Assuming the socket option is the most economical conduit between AppForge and the Palm/GPS libraries, then the socket can be controlled via the AppForge-side by sending 'verbs' to the C application. That way, the AppForge app governs the polling frequency.

I've never see an external call in AppForge anywhere that I've looked. The other aspect with AppForge is the necessity to use their Booster which is device dependent and handles the low-level calls between the AppForge app and the OS. You can't run AppForge apps without the Booster. They've just released the Crossfire product for VB and the C# version is due sometime in the new few months. I think that all Crossfire offers is a complete OO environment, something that no one could say VB6 is.