Jump to content

Roger Cigol

Members
  • Content Count

    305
  • Joined

  • Last visited

  • Days Won

    4

Posts posted by Roger Cigol


  1. I too migrated a system away from Paradox a long long time ago. Paradox was good in it's time but it's limitations (particularly for a multi-user interface to the database) are very significant. I would definitely migrate to a modern and supported database (there are several open-source type solutions that are only a free of charge download away....)

    • Like 1

  2. If you are displaying message boxes in your code, you are presumably displaying text inside them. So if you are worried about the language of the buttons you presumably have a strategy for handling different languages for the text that you are displaying in the box. Surely you can use the same strategy to translate the button captions?

     

    I frequently use my own dialog boxes and ShowModal() rather than the OS message boxes. One advantage I find is that when users ask for support over the phone it is much easier to determine if the message box is generated by my code (because I give it a red or blue background (for error or warning)) or if the message box is generated by the OS (in which case it is in the standard OS colours). I haven't found any problems with this approach.


  3. 1 hour ago, Fraser said:

    The standard says when argc>0 argv[0] holds the program name or is empty.  What I see is my parameter, which is neither of those.

    But you said originally that in your case argc was equal to zero (ie it is NOT > 0). 


  4. .... and I'd knock this out very quickly using Embarcadero C++ and VCL. You could use radio buttons as you say (the correct native choice) and you would use the same form and just populate the text next to each radio button with the multiple choice answer. A Delphi fan would be equally at home doing the same with Delphi and VCL. Or use Firemonkey if you want to target mobile devices. Actually there is very little code required here - it's mostly visual layout stuff. So the choice of language is not a major decision. Pick the one you are most familiar with (if you want to get it done quickly) or pick the one you want to learn if getting new skills is what you are after....


  5. Twenty five or so years ago I took on maintenance / on going development of a large C++ project based on MS Visual C++ and MFC (version 6).  I got the customer's main issues sorted out over a couple of years and in doing so got to know the ins and outs of Visual C++ /MFC 6.0. The customer got confidence in me then and I suggested migrating to Borland C++ Builder / VCL version 6.0 . This took another year to get done. I am still supporting and developing this product for the same customer and it's now on Embarcadero C++ 11 and we are about to change to a 64bit based version of the software..... This is (one of the reasons) why I am really excited and pleased about David Millington's recent blog about the Embarcadero future direction for clang C++....


  6. Also for simple conversions from String types to integer types you may like to use the ToIntDef() String member function. Pass this a default value which is the value returned if the String variable does not contain a valid integer.  (The ToInt() function throws an exception if the String cannot be converted to an integer).


  7. "It worked" does not mean that the code is sensible or ideal. You don't need / want to convert the int value called sum to an AnsiiString. you actually want to convert it to a C++ Builder String type (whichi is actually a UnicodeString). So you would be better to have used 

    Label3->Caption = String("The sum is ") + String(sum);

  8. For anyone interested I have solved my problem. I have an abstract base class (called TThreadStateMachine) that I use to derive classes for code units that run in their own threads and are state machine based control. The base class has a virtual function that forms the basic periodic tick of the derived class state machine.  The  TThreadDataInterface_TS template class is used to provide thread safe communications to / from the state machine.

    The problem comes when the derived classes, based on TThreadStateMachine are destroyed. The C++ standard ensures that the derived class destructor is called BEFORE the base class destructor. But because the base class was still running it's own thread it was (sometimes) causing the derived class state machine to "Tick" even when parts of it have been destroyed. My solution to this was to create a new base class function AbortThread() and make sure I call this in the derived class destructor before doing any further destruction. Now it passes many many iterations of a unit test creating and destroying without an error. I believe all is good now.

     

    One mystery may never be solved.:Why dic my poor original implementation never seem to cause a problem on Linux / GNU C++ ?

    • Like 1

  9. I am puzzled / worried. I've just checked out (of Git) the previous version sent to the customer as a compiled and working *.exe file and this now won't link - giving the same out of memory error. What can change that causes the linker to work with the source code at some point and then later not work ? where should I be looking to solve this problem ?


  10. Hi Hans, Sorry about wrong word in my original question: I have edited this to read "diagnostic". Sometimes I have seen TwincCompile catch these messages, but sometimes not. For testing, once you have all the files compiled (takes 10 mins with twine compile) I turn Twine Compile off, Set verbosity to diagnostic and do a "make" again. This checks all object code is still ok (it is) and then jumps straight to doing the linking. The output I get is as follows (edited to save space and maintain customer confidentiality):

    Done building target "_CheckLinkDependencies" in project "MYPROJECTNAME.cbproj".
    Target "_PerformLink" in file "d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets":
      Task "CallTarget"
        Target "_PerformBCCILink" in file "d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets":
          Using "ILINK32" task from assembly "d:\program files (x86)\embarcadero\studio\22.0\bin\Borland.Build.Tasks.Cpp.dll".
          Task "ILINK32"
            d:\program files (x86)\embarcadero\studio\22.0\bin\ilink64.exe -G8 -L.\Win64\Release;"BIG LONG LIST OF OBJECT CODE FILES HERE", .\Win64\Release\MYPROJECTNAME_resources.res .\Win64\Release\MYPROJECTNAME.res 
            Turbo Incremental Link64 6.97 Copyright (c) 1997-2022 Embarcadero Technologies, Inc.
            d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): warning : Warning: Out of memory
            d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): error MSB6006: "ilink32" exited with code 2.
          Done executing task "ILINK32" -- FAILED.
        Done building target "_PerformBCCILink" in project "MYPROJECTNAME.cbproj" -- FAILED.
      Done executing task "CallTarget" -- FAILED.
    Done building target "_PerformLink" in project "MYPROJECTNAME.cbproj" -- FAILED.
    Done building project "MYPROJECTNAME.cbproj" -- FAILED.
    Build FAILED.
    d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): warning : Warning: Out of memory
    d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): error MSB6006: "ilink32" exited with code 2.
        1 Warning(s)
        1 Error(s)

    As you see: I do NOT get any indication of which heap size has caused the memory overflow.

    If I repeat the make with Vertosity set to "Normal" I do get slightly less information in the output - so the setting is having some effect.

    But no sign of any heap information.....

×