Our Professional customers (which we have quite a few Airlines, ATC and Agencies) do use the RadarBox but do not use the .rbl files or the 30003 port data. They use a different interface altogether and we haven't had issues with them regarding this.
That's good news.
If you are saying that there is an alternative way of getting data out of RadarBox that's reliable then I would welcome details and, if satisfied, will happily put RadarBox back onto the shortlist for use in developing professional solutions.
Still awaiting aforesaid details !
In the meantime it occurs to me that, if it's true what you're saying and you have other versions of RadarBox that don't suffer from the "hex code confusion" bug, then why on earth aren't you using the same data handling routines in the RB version that we're all running ?
It does seem strange, though, that you are blaming the external data output interface for the hex code errors, I would have thought that they originated further upstream, in the decoding process.
And are you absolutely sure that it's only the amateur version of RadarBox that has this bug ? I can understand any vendor's reluctance to acknowledge defects in their software but, as any developer will tell you, honesty is always the best policy.
Anyway, taking your statement at face value, can you please tell me how can I obtain an evaluation copy of the bug-free professional version of the RB software to confirm that that's the case and to see if it would be suitable for my clients ?
I'm hoping that all the work I've done on analysis over the last couple of days won't turn out to have been a waste of time. Having said that, pending a bug-fix I've at least saved myself the potential embarrassment of recommending a solution that I would later regret.