[Ray Konopka]

Welcome back! CodeSite’s support for C++Builder is actually provided by the Delphi compiler. That is, the source code is written in Delphi and we first compile it for Delphi and then compile it again using a command line option which causes the compiler to produce the necessary files for use in C++Builder. The .NET logging assembly is written C# and can be used in any .NET managed application. Providing CodeSite support for Visual C++ would require creating a native C++ logging module, which while certainly possible, it is not a trivial matter.

Ray

[Ray Konopka]

Hi Olivier,
There are a few things that I would suggest. First, I would make a report to Embarcadero about this issue as they have been the owners of the components since 2015. Second, the simplest way to handle this for all your clients would be to blank out the Format property, which would use the System defined ShortDateFormat. As for modifying the source code yourself, the approach that I would take would be to do something similar to what is done in the StrToTimeEx function and that is to use the Format property to guide the property. The UseFormatToParse property was added to handle parsing Time values that include other elements not in a format. The same approach could be used to handle date parsing. The only challenge is that the condensing code would need to be tweaked a little to handle the leading ddd in your format string so that it does not get confused for the day elements.

Ray

[Ray Konopka]

I was able to reproduce the problem that you are experiencing. I changed the format settings for Windows to be French (Canada). I only changed the general Format setting. I did not change any of the actually date/time formats.

I then created a test project that has a TRzEdit and a TRzDateTimeEdit control on the main form. I put the TRzEdit so that I could tab into and out of the TRzDateTimeEdit. I also set the Format property of the TRzDateTimeEdit to ‘ddd dd-mmm-yyyy‘. I ran the app, click on the date-time edit and picked today’s date. I then clicked on the other edit control and that is when I got the exception.

After some investigation, I was able to see why the error was occurring. Let me try to explain. As you discovered, the TRzDateTimeEdit uses the StrToDateEx function to parse the information in the edit to determine the date. Because a user is able to enter a date in the control and not select one from the dropdown calendar, the data that gets parsed could be in a variety of formats. In order to interpret the data entered and match it to date elements, the system ShortDateFormat is used as a guide. Well, actually an abbreviated version of the ShortDateFormat is used. For example, the default ShortDateFormat for French(Canada) is yyyy-MM-dd. This gets condensed to YMD. For English(United States), the ShortDateFormat is M/d/yyyy, which gets condensed to MDY. And for English(United Kingdom) the format is dd/MM/yyyy, which gets condensed to DMY.

This approach is how the control is able to handle someone from the US entering 0405 into the control, tabbing away and the date is determined to be April 5. However, someone from the UK entering 0405 into the control will have the date determined to be May 4.

So, what does all of this have to do with what you are experiencing. Well, the condensed ShortDateFormat for French (Canada) as noted above is YMD. However, the Format property of the control is set to ‘ddd dd-mmm-yyyy‘, which gets condensed to DMY. And this is the problem. The parsing code is trying to match the values in the text area to YMD, but the year and day values are swapped. The parsing code ends up matching 2019 to the day value, which is clearly invalid.

The easiest solution is to change the Format property of the TRzDateTimeEdit control to ‘ddd yyyy-mmm-dd‘ so that it matches the YMD ShortDateFormat defined in the system.

Ray

[Ray Konopka]

Hi Olivier,
I will need to do some research on this. What version of Delphi are you using?

Ray

[Ray Konopka]

The only way to change the behavior would be to modify the source code for the control. However, a simple alternative would be to use two buttons. One regular tool button with a unique GroupIndex and AllowAllUp set to True. Then use a separate tool button set to tsDropDown style and just resize it to make it thinner. You can even place it right next to the other button.

Ray

[Ray Konopka]

I apologize for the delay. Had to do some more research on this. The help file itself is valid and does have all the content. However, after some research I believe I have discovered the issue. Apparently, Microsoft has added more security checks on HtmlHelp files (*.chm) in recent releases of Windows. As a result, if a file is marked as being downloaded from the Internet, then the content page of the HtmlHelp file is blanked. The solution is to right-click on the help file and select Properties. At the bottom of the property page you will see a button to Unblock the file. After unblocking the file, you will then be able to see the content.

Ray

[Ray Konopka]

Hi Barry,

Thank you for bringing this to our attention. I checked out the CodeSite5.chm file and it worked fine for me. I then downloaded the zip file from the link above just to make sure something didn’t happen to the file during the zipping/uploading process. I downloaded the zip file to my system and saved it to a shared drive that my VM has access to.

Sure enough, when I opened the help file, I did see the issues that you described. That is, the table of contents is displayed, but the content view pane is empty. Very odd indeed.

Then I remembered that the CodeSite5.chm file was located on a network drive (from the point of view of my VM) and so I moved the file to a directory on the VM’s local drive. Then the help file was opened correctly. I believe the content display issue is a result of the Windows HtmlHelp viewer and not the help file itself, as I see the same issue with other *.chm files on a network drive.

Where precisely is the CodeSite5.chm file located on your system?

Ray

[Ray Konopka]

Hi Andreas,

Yes, I absolutely agree that the control should operate correctly under HighDPI settings. I would strongly encourage you to report this issue to Embarcadero. I will continue to encourage Embarcadero to address issues like this, but it will help if endusers are also reporting the issues.

Ray

[Ray Konopka]

Hi,
The behavior you are seeing is by design. Let me try to explain. The DropDown style allows a drop-down menu to be associated with the button. So that when you click on the arrow, a popup menu is displayed and the user can select one of the items from the menu. If you have an OnClick event handler (or an Action) assigned to the button, then the drop-down arrow portion is separated from the button itself. This allows you to have the button click perform some default behavior. Think of the File Open button in RAD Studio. The drop-down arrow provides access to a recently used list of files, and the button click displays the Open Dialog.

The GroupIndex property is used in situations to allow the button to behave like a check-box or radio button. If the GroupIndex property value is shared across multiple buttons, then only one button in the set can be down at a time. Think of a set of text alignment buttons (Left, Center, Right). Only one of the buttons can be pressed at a time. If the GroupIndex values are unique for each button, then each button can work like a toggle. Think of the Bold, Italics, and Underline buttons.

The AllowAllUp property works with the GroupIndex property to determine if all the buttons in a group (even a group of one) can all be in the Up state, or does one button have to be down.

As a result, having a ToolButton in the DropDown style does not really fit in with the behavior of the grouping.

Ray

[Ray Konopka]

Hi Barry,

Thank you for the report. We apologize for the inconvenience. There is an issue with the CodeSite Express installer. We are working on fixing the issue and sending a new installer to Embarcadero for use in the GetIt Package Manager. In the meantime, you can download the CodeSite Help file from the following link:

https://raize.com/wp-content/uploads/CodeSite5Help.zip

Unzip the CodeSite5.chm file and copy it to the Raize\CS5\Help directory.

Ray

[Ray Konopka]

Hi Dave. Thank you for bringing this to our attention. Yes, the parser needs to be updated to handle inline variable and constant declarations introduced in Rio.

Ray

[Ray Konopka]

The Palette Menu for 10.3 is now available for download.

As for multi-column, I’m not sure what you are referring to. You can use the Palette Menu to group pages into separate categories which show up as cascading menus, but it is not really column based.

Ray

[Ray Konopka]

Hi,
The issue is that the new installer that Embarcadero created for the KSVC for 10.3 Rio did not add the necessary directories to the C++ related paths. I have already reported this issue to Embarcadero. In the meantime, you can resolve the issue manually by following the steps below.

In order to fix the issue, we need to add the appropriate KSVC directories to the System Include and Library paths for the C++ compilers. To make the instructions easier to read, consider the following two variables, which define the two paths that are needed.

KSVC_PATH_WIN32=$(BDSCatalogRepositoryAllUsers)\KonopkaControls-260-6.2.3\Lib\RX10.3\Win32

KSVC_PATH_WIN64=$(BDSCatalogRepositoryAllUsers)\KonopkaControls-260-6.2.3\Lib\RX10.3\Win64

Please perform the following steps:

1. Close all files in RAD Studio 10.3
2. Open the Tools > Options dialog
3. User the tree on the left and navigate to Language > C++ Options > Paths and Directories
4. Select “Windows 32-bit” in the Selected Platform combo box
   a. Make the “Compiler” tab active
      i.  Edit the System Include Path value and add the KSVC_PATH_WIN32 value to the path
      ii. Edit the Library Path value and add the KSVC_PATH_WIN32 value to the path
   b. Make the “Classic Compiler” tab active
      i.  Edit the System Include Path value and add the KSVC_PATH_WIN32 value to the path
      ii. Edit the Library Path value and add the KSVC_PATH_WIN32 value to the path
5. Select “Windows 64-bit” in the Selected Platform combo box
   a. Make the “Compiler” tab active
      i.  Edit the System Include Path value and add the KSVC_PATH_WIN64 value to the path
      ii. Edit the Library Path value and add the KSVC_PATH_WIN64 value to the path
   b. Make the “Classic Compiler” tab active
      i.  Edit the System Include Path value and add the KSVC_PATH_WIN64 value to the path
      ii. Edit the Library Path value and add the KSVC_PATH_WIN64 value to the path
6. Click the Save button to close the Tools > Options dialog box and save the changes
7. Reopen your project. You should be able to build and run your project now.

Ray

• This reply was modified 5 years, 4 months ago by Ray Konopka.

[Ray Konopka]

Hi Navid,

I am able to see KSVC in the GetIt Package Manager for 10.3 Rio. I searched for “KSVC” and the Bonus KSVC 6.2.3 item appeared in the list.

Ray

[Ray Konopka]

Hi Rich,

Yes, CodeSite does support dynamically changing the log file. I suspect that you are changing the original TCodeSiteDestination object when you change the FilePath and not the CodeSiteManager’s DefaultDestination property (or an individual logger’s Destination property).

The CodeSiteManager.DefaultDestination property is not a component reference property. It is more like the Items property of a ListBox. You can assign a TStringList to ListBox1.Items to populate the list box. But if you change the contents of the string list, the list box does not get updated. Here is some sample code that should help illustrate the situation:

uses
  CodeSiteLogging;

procedure TForm1.FormCreate(Sender: TObject);
var
  Dest: TCodeSiteDestination;
begin
  Dest := TCodeSiteDestination.Create( Self );
  Dest.LogFile.Active := True;
  Dest.LogFile.FilePath := 'C:\Temp';
  Dest.LogFile.FileName := 'Sample.csl';

  CodeSiteManager.DefaultDestination := Dest;
end;

procedure TForm1.btnSampleMessageClick(Sender: TObject);
begin
  CodeSite.Send( 'Sample Message' );
end;

procedure TForm1.btnChangeLogFileClick(Sender: TObject);
begin
  CodeSiteManager.DefaultDestination.LogFile.FileName := 'NewLogFile.csl';
end;

The form simply has two TButtons dropped on to it. At the start the DefaultDestination is set to log all messages to the Sample.csl file. Clicking the btnSampleMessage button simply sends a simple CodeSite message. The messages will be logged to the Sample.csl file.

When the btnChangeLogFile button is clicked, the LogFile.FileName property of the CodeSiteManager.DefaultDestination is changed. Now, when the btnSampleMessage button is pressed, the CodeSite message will be sent to the NewLogFile.csl file.

As an alternative, you could create a new CodeSiteDestination object with the updated FilePath and then assign that to the DefaultDestination property.

Ray

[Author]

Posts