-
braindead0 committed revision 57 to the InterBase and Firebird Coexistance SVN repository, changing 2 files.
2007-08-03 12:47:23 UTC in InterBase and Firebird Coexistance
-
braindead0 committed revision 56 to the InterBase and Firebird Coexistance SVN repository, changing 1 files.
2007-08-03 12:21:11 UTC in InterBase and Firebird Coexistance
-
braindead0 committed revision 55 to the InterBase and Firebird Coexistance SVN repository, changing 2 files.
2007-08-03 12:14:48 UTC in InterBase and Firebird Coexistance
-
Thanks for the help folks! One of the two changes I made fixed the problem, not a hickup running all night!
Thanks again!
2007-04-18 12:10:48 UTC in TurboPower Async Professional
-
The main problem with out application is that it's legacy DOS.. And we couldn't refactor the entire thing into an even driven framework without breaking the UI. That would be find and dandy, if the existing ugly DOS UI wasn't effectively an industry standard that 1000's of people understand and now how to use. The need to retrain was a huge factor.
2007-04-18 12:09:58 UTC in TurboPower Async Professional
-
I'm outta here for the evening, I'll post results first thing in the morning.
2007-04-17 21:31:55 UTC in TurboPower Async Professional
-
Thanks for the suggestion, I've made that change (as well as checking CharReady rather than InBuffUsed). Usually takes a bit for the problem to manifest.
We're only using TApdComport, created dynamically. Here's the init as it stands now (added TriggerLength := 0):
ThisComm := TAPDComport.Create(nil);
ThisComm.CommNotificationLevel := 0;
ThisComm.TriggerLength := 0;.
2007-04-17 21:29:11 UTC in TurboPower Async Professional
-
APD is way less CPU intensive in the current system, in particular servicing multiple comports. At least with the various other lightweight, direct to WinAPI (readfile,writefile) methods I've tried so far.
One should be able to call GetChar without fear of bogus data.
That being said, I may have an idea. I was checking for InBuffUsed > 0 to determine if a character is ready, that's...
2007-04-17 21:24:44 UTC in TurboPower Async Professional
-
I probably should have qualified 'heavy load'. It's not CPU load, just serial traffic. We are not overrunning any buffers (not even close).
2007-04-17 20:58:41 UTC in TurboPower Async Professional
-
That would be fine and dandy, if we could. This is a legacy product, originally written in DOS that's been ported to Windoze (wasn't my idea, but I couldn't get them to let me port it to *nix ;-).
It's fairly large and complex and runs as a service, or in test mode as a console application.
As far as yeilding control, the application uses on average under 2% CPU.. so it's not a case of...
2007-04-17 20:56:36 UTC in TurboPower Async Professional
