Jump to content

Roger Cigol

Members
  • Content Count

    299
  • Joined

  • Last visited

  • Days Won

    4

Posts posted by Roger Cigol


  1. "Which is the best way?" questions in C++ are always tricky! The language has evolved so much (and continues to do so). We C++ Builder users have the added complication of the use of the VCL or FireMonkey functions (that come from the Delphi RTL). How important it is to keep your code portable is certainly one question to consider. Re: text files : also take into account encoding possiblities - if you need to anticipate different encodings then the VCL support is often the easiest route. I tend to use TStringList as the store and then the LoadFromFile() and SaveToFile() functions.


  2. I don't actually see that you have to do anything here - just don't take any action for the case(s) you want to ignore.  If you do want to skip an extra step you can always deliberately increment the counting value - ie use this line inside the loop....

    i = i + 1; 

     


  3. Hi @Lajos Juhász

    Thanks for this. Usually editing techniques apply equally to Delphi or C+. I have the datamodule on the screen. But under my View menu I do not have a "View as text" option (is it somewhere else?). However alt+F12 does indeed change the form view to the text equivalent. Here I can manually edit the field (or anything else!). And alt+F12 toggles it back afterwards. I never knew this short cut (after all these years.....). So this saves me manually cutting and pasting to a different text editor. This may be useful to me in the future.

    It does still strike me as not being a RAD Studio IDE elegant way to edit a property. I wonder why the field type does not appear in the "properties" pane? I can visualise that there could be a good reason for this but if so it would be much better if a right click on the field in the structure display also gave me an option to bring up a window the same as the "new" field window - where I could then adjust the type. 

    May be I'll put in a feature request when the quality portal comes back from its "holiday"......


  4. I have a Win64 C++ Builder VCL FireDAC application. I have a TFDQuery that is used as the source for a TBindSourceDB component which in turn is used for livebindings for conveniently displaying the query results on a string grid.

    With the change from RAD Studio 11 to RAD Studio 12 (patch 1) came the introduction of better support for fields of TimeStamp with offset (timezone) types. With RAD Studio 11 it seems that these were just treated as TimeStamp

    fields (ie the time zone offset was ignored). Code that worked in RAD Studio 11 stopped working in RAD Studio 12 (patch 1) and I traced the problem to the fact that one of the field definitions for this particular TFDQuery now needed

    to be changed from type TSQLTimeStamp (which worked in 11.) to TSQLTimeStampOffset (which works in 12-patch 1). The underlying type in the postgreSQL database for this field has always been "time stamp with time zone".

    I have this all understood and it is all now working following this change of type.

    MY QUESTION

    Is there a convenient way to change the TYPE of a field definition through the IDE? I couldn't find a way to do what you would think should be a simple task. In the end I "cut" the query component to the clip board, pasted it into a

    text editor, changed the type as described above, copied the text editor contents to the clip board and then pasted it back into the VCL data module. Not actually too difficult but hardly what you would expect to have to do in a

    RAD Studio IDE! I suspect I am missing a trick, hence this appeal for advice....

    Attachments: file "Structure.jpg" shows the field (after my change of data type) selected in the structure pane. In the properties pane there are lots of properties, but not (or I couldn't find it!) the field type.

    "NewField.jpg" shows the "wiard" form that appears if you add a new field to the field definition - here there is a drop down box in which all the possible field types appear and you can pick the one you need.

    But I can't find a way of getting this box up again for an existing field...

     

    (Not sure if this should have been posted under category: IDE, VCL or Database - so I went for "Database").

    Structure.JPG

    NewField.JPG


  5. Hi Ian,

    May I respectfully suggest that posts with titles such as "Is it just me?" and "-ummmm what" don't help other users of this forum when they may be searching for solutions to the same or similar problems to your posts.

    Surely the title is intended to be a brief summary of what the post is about. You may get someone reading it who knows the answer if you choose your title correctly. 

    • Like 1
    • Thanks 2

  6. I have just installed RAD Studio 12.0 path 1 using Getit. It all ran through smoothly - no errors reported. I got the readme displayed at the end with the patch 1 information. 

    My original installation was done from the downloaded RAD Studio 12.0 ISO. 

    I can build a complex VCL C++ 64 bit project - no errors, as before (using TwineCompile).

    Only problem I have is that the IDE still says "patch available" and the Help | About does not mention the patch 1 upgrade.

    Note; My installation is a bit unusual in that my original install is to D:\Program Files (x86)\Embarcadero\Studio\23.0   Note; D drive rather than C drive !

    Using BeyondCompare on the data obtained by Help | About and then clicking on "Version Information...." does show many newer version numbered files 

    and in my ....\Studio\23.0 installation directory I do have a new directory called _patch-backup which contains all the old files, so I am sure my patch installation

    has gone in ok.

     

    I really like the visual assist integration in C++ for RAD Studio 12.0. It all seems to work well and is a very useful addition to the editing experience.

     


  7. I have spotted this warning about the patch 1 for C++ users....

    Oliver Weinheimer

    I just installed the patch. I’m a C++ user – couldn’t build my projects with 12.0, when building a package components don’t show up. But this is another story. OK.

    At least I was able to build test projects with 12.0. Now after the patch, RAD Studio can no longer link a bare C++ VCL project without anything in it for Win64 (Win32 works). For Win64 I get:

    [ilink64 Error] Fatal: Unable to open file ‘;E:\RADSTUDIO12BETA\JEDI\JCL-MASTER\JCL\LIB\D29\WIN64;C:\USERS\x y\DOCUMENTS\EMBARCADERO\STUDIO\23.0\CATALOGREPOSITORY\JEDICODELIBRARYJCL-2023.11\LIB\D29\WIN64;C:\USERS\PUBLIC\DOCUMENTS\EMBARCADERO\STUDIO\23.0\DCP\WIN64\RELEASE;C:\USERS\PUBLIC\D’

    The only thing I did was installing the patch!!!

     

    Oliver posted this in the comments section at the bottom of this page

    https://blogs.embarcadero.com/getit-update-additional-rad-studio-12-getit-packages-are-now-available/

     


  8. No - All the IDE is 32 bit. 

    This is a pain when (in my case) I want to work with PostgreSQL as all the more recent versions of PostgreSQL are only available as 64bit servers. So I lose all the (neat and nice) design time execution features of FireDAC.

    No real way round this (and there is little sign of Embarcadero IDE moving to 64bit in the near future)


  9. If you want to write portable C++ that will compile outside of VCL then you have to avoid all VCL classes (eg String).

    If you just want the thread implementation to be able to compile outside of VCL then avoid VCL thread classes (which do work for C++ Builder of course) and use std::thread from the C++ STL.

    (std::thread also works fine for RAD Studio 11 (and 12 of course)).

     

    Not sure why your two include statements should cause problems. I use exactly this in code, regularly.

     

    does 

    #include <string>

    or

    #include <vector>

     

    also throw up compile time errors?

     

     


  10. I thought I would add some code with "what doesn't work" and how to use the above two functions to make it work.

    Assume you have a postgreSQL database connected and that you have a query that returns a record that contains a date/time value and that the database stores this value as a "time stamp with time zone" format (PostgreSQL users can call this timestamptz).

    I would expect the following code to work - but after you run it AllOkA is true (showing it works for UTC local time) but AllOkB is false (showing it falls over for BST (British Summer Time)).

             TFDQuery *FDQuery = SampleFDQuery;  // a query which returns a record with a timestampwithoffset field
             FDQuery->Close();
             // work with the oldest record (any one would do)
             FDQuery->ParamByName(SSQP_PrimaryKey)->AsLargeInt = 1;
             FDQuery->OpenOrExecute();
             FDQuery->First(); // should only be one entry
             TField *Field = FDQuery->FieldByName(PG_Sensors_TimeDate);
             // try a winter time (January)  (this is UTC - works without special function calls
             TDateTime WinterLocalDateTime{2020, 1, 17, 9, 8, 7, 0};
             FDQuery->Edit();
             Field->AsDateTime = WinterLocalDateTime;   //=== 
             FDQuery->Post();
             FDQuery->Close();
             FDQuery->OpenOrExecute();
             Field = FDQuery->FieldByName(PG_Sensors_TimeDate);
             TDateTime Check = Field->AsDateTime;  //=== 
             FDQuery->Close();
             AllOkA = (WinterLocalDateTime == Check);
             if (AllOkA) {
                FDQuery->OpenOrExecute();
                Field = FDQuery->FieldByName(PG_Sensors_TimeDate);
                // try a summer time (June) (BST - one hour ahead of UTC)
                TDateTime SummerLocalDateTime{2020, 6, 17, 9, 8, 7, 0};
                FDQuery->Edit();
                Field->AsDateTime = SummerLocalDateTime;  //=== 
                FDQuery->Post();
                FDQuery->Close();
                FDQuery->OpenOrExecute();
                Field = FDQuery->FieldByName(PG_Sensors_TimeDate);
                Check = Field->AsDateTime;  //=== 
                FDQuery->Close();
                AllOkB = (SummerLocalDateTime == Check);
             }

    If I replace the lines with comments //=== with calls to the functions given in my previous posting I get code that works for both winter and BST summer times (ie both AllOkA and AllOkB are true at the end of the code).

             TFDQuery *FDQuery = SampleFDQuery;  // a query which returns a record with a timestampwithoffset field
             FDQuery->Close();
             // work with the oldest record (any one would do)
             FDQuery->ParamByName(SSQP_PrimaryKey)->AsLargeInt = 1;
             FDQuery->OpenOrExecute();
             FDQuery->First(); // should only be one entry
             TField *Field = FDQuery->FieldByName(PG_Sensors_TimeDate);
             // try a winter time (January)  (this is UTC - works without special function calls
             TDateTime WinterLocalDateTime{2020, 1, 17, 9, 8, 7, 0};
             FDQuery->Edit();
             UpdatePgSQLDataSetFieldIfNotDefaultDate(Field, WinterLocalDateTime); //===
              FDQuery->Post();
             FDQuery->Close();
             FDQuery->OpenOrExecute();
             Field = FDQuery->FieldByName(PG_Sensors_TimeDate);
             TDateTime Check = GetPgSQLDataSetFieldAsLocalTime(Field); //===
             FDQuery->Close();
             AllOkA = (WinterLocalDateTime == Check);
             if (AllOkA) {
                FDQuery->OpenOrExecute();
                Field = FDQuery->FieldByName(PG_Sensors_TimeDate);
                // try a summer time (June) (BST - one hour ahead of UTC)
                TDateTime SummerLocalDateTime{2020, 6, 17, 9, 8, 7, 0};
                FDQuery->Edit();
                UpdatePgSQLDataSetFieldIfNotDefaultDate(Field, SummerLocalDateTime);//===
                FDQuery->Post();
                FDQuery->Close();
                FDQuery->OpenOrExecute();
                Field = FDQuery->FieldByName(PG_Sensors_TimeDate);
                Check = GetPgSQLDataSetFieldAsLocalTime(Field); //===
                FDQuery->Close();
                AllOkB = (SummerLocalDateTime == Check);
             }

    I do not have a copy of Microsoft SQLServer but I would think it very likely that the same problem exists with this too.  (but am wise enough to wait for someone else to verity this !).


  11. Just posting this in case anyone else out there is wasting their time on this.....

    It seems that there is currently a problem with using the Clang compilers in RAD Studio 12.0 with the GoogleTest framework on getit. The version currently (Jan 2024) available does not build correctly.

    I will monitor this situation and blog here as soon as Embarcadero have a working GoogleTest framework on getit.

     


  12. It is very unusual to want to create an XML file and then at some later time set the values. What purpose does an XML file with no values in serve? How you create an XML file from data values that you have is (probably) your question. The answer to this may depend on where the values are coming from.

    The Embarcadero XML mapper tool (available on Getit - EXCEPT AT THIS MOMENT IN TIME (JAN 2024) GETIT IS BROKEN) allows you to take <at design time> an existing *.xsd schema and create a transofrmation that can then be used in your code so that <at run time> a TClientDataset can generate an XML file from the data it contains. 

    I am aware that I am not helping with the "using OmniXml" part of your question but I mention the above in case it helps.

    • Thanks 1

  13. I think I have found the area of my problem. If I put my breakpoint(s) in areas of code where "normal" code functions are happening then all is well. The opposite of "normal" is if I put a breakpoint in code that is interfacing with my postgreSQL (version 13 - 64 bit) database inside a database transaction then the debugger seems to hang / or do all sorts of bad things. I have my postgreSQL configured with various time outs. It makes debugging complicated database interaction (with several TFDQuery updates being used in one transaction) a bit tricky - but the IDE seems reliable if I avoid this - which is something that is workable.

     

×