CPortTypes in ComPort library for XE

vlad
2011-08-14
2013-04-30
  • vlad

    vlad - 2011-08-14

    Hello, I am trying to adapt a project with comport library created in Delphi 2010 to Delphi XE. In the Delphi 2010 I worked with TComPort version 4.0 which includes CPortTypes.pas. The latest comport411c, which I installed in Delphi XE, does not have this file. As seems for me to have this unit looks reasonable as it allows working in the project with different comport libraries and compare their performance .    

     
  • Brian Gochnauer

    Brian Gochnauer - 2011-08-14

    You best solution is to use the same comport library in both versions.
    The 4.0 versions and 4.11 versions are VERY different.
    4.0 was an attempt at a complete rewrite; 4.11 is a simple update from 3.10 to accommodate  Delphi compilers (>2009) that default to using UnicodeStrings.

     
  • Warren

    Warren - 2011-08-14

    They are very different, in that the 4.0 version I did some refactoring.  In Delphi 7, TComPort strings were AnsiStrings, and chars were AnsiChars, and in the 4.0 version, on a unicode version of delphi, they were still the same.

    Personally, I'm not very fond of the way 4.11 uses UnicodeString for bytes that come from the com port, and feel that 4.0 was a better fit for my purposes.  For that reason, I wish that 4.11 had been called something else, maybe even 5.0, or 3.5?

    I think that a community poll should be done;  "Should TComPort use wide chars and bytes everywhere, or continue to be compatible byte-for-byte with Delphi 1.0-7.0 TComPort users".

    Warren

     
  • Brian Gochnauer

    Brian Gochnauer - 2011-08-14

    What I found when I tried to complete your refactoring is;

    1.The rest of the application and users' components are based on Unicodestring  with TComport based on Ansistring at some point you have to do a conversion. This can become tedious and error prone when you have many places that call TComport or reference strings and arrays in the application which would be unicode when comport is using ansi.

    2. Errors show up as a warnings not as errors when a String is used where Ansistring is really required.

    3. String manipulation of chars and enumeration statements like s whether unicode or ansi still reference ONE character properly and so code like

    var s:string
       s := #34+#45+#23 ;
       Comport1.writestr(s);

    compile and work as expected without conversion.

    4. Fewer or even no code changes for the programmer (including me) to go from 3.10 to 4.11 when using strings, chars and array of chars for I/O.

    But I agree numbering it as 4.10 was a bad choice.

    Maybe there should be a byte array interface added.

     
  • Brian Gochnauer

    Brian Gochnauer - 2011-08-14

    I think that a community poll should be done;  "Should TComPort use wide chars and bytes everywhere, or continue to be compatible byte-for-byte with Delphi 1.0-7.0 TComPort users"

    Nearly all the calls use strings for data I/O except for the calls that use an untyped buffer; which is very error prone.
    So I'm not sure what you mean by byte-for-byte compatible with seriously obsolete compilers.
    Although I maintain a Delphi 5 app using ComPort and I upgraded it to 4.11 with no issues and no rewrites

     
  • Paul Vandermyde

    Paul Vandermyde - 2011-09-29

    Has anyone tried to install on XE2 yet or for that matter Firemonkey?  When I was using the trial version Of XE2 the component worked just fine. (had decided I was not going to upgrade unless Comport worked, from D2010 to DEX2). When I "upgraded" to the Pro version it quit working.  By this discussion it appears I may be better off using 4.10, Which I can give a try tonight when I get home.

    Just for kicks, when the component did work in the trial version, I tried to compile the program using the 64bit compiler and it did not work for a reason I do not remember.

    Any thoughts?

    Probably opening another can of worms….  Is there any hope that this will work on an Apple OS computer. My gut reaction is no since the component uses Windows APIs.  But I would like to be wrong on this.

    Paul Vandermyde

     
  • S. Michel

    S. Michel - 2011-09-29

    In Firemonkey the only components that are installed are TComPort and TComDataPacket.

    TComComboBox, TComRadioGroup, TComLed and TComTerminal are missing because they all use the VCL.

     
  • Anonymous - 2011-09-30

    @pvandermyde:   Paul…

    1. it would have been better to start a new thread.

    2. the components "not working" - you better give some better details than "not working".  Describe exactly what you did and what you tried. This is standard etiquette. Please observe it.

    3. Mac????  Ha! Don't even ask. These things wrap the Win32 API CreateFile apis.  If you want to rewrite them for Mac, then please do. But first tell me how you plan to get a working serial port in a mac os x box?  The last drivers I know for a USB-to-serial converter that worked on Mac OS at all stopped working on Mac OS X 10.2, about 5 years ago.   I don't believe I have ever seen native Intel-mac drivers for OSX leopard, snow leopard, or lion, for a usb serial port convertor.

    W

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks