Forum Replies Created
-
Posts
-
Hi Martijn,
While the google results may not show it, other users are indeed running into these sort of HighDPI related issues with the components. Embarcadero has done quite a bit of work in the VCL to provide better support for HighDPI, and I keep asking when the same work will be applied to KSVC (Embarcadero acquired KSVC in 2015), but as of yet no work has been done. It is very disappointing. As such, I would strongly suggest that you submit your bug report to Embarcadero.
Ray
Hi Barry,
Sorry for the delay. I missed your response. Anyway, I created a brand new VCL app in 10.3.3 to try out the version info and everything worked as expected. Specifically, I just created a new VCL Forms app. Dropped a TRzVersionInfo component and a few TRzVersionInfoStatus controls on the form. I hooked them all up and then went into the Project Options (Version Info was already turned on). I then changed the Version fields (which updated the FileVersion property). I also changed the Product Version field to be something different so that I could test both status fields. All the data was displayed correctly.
I then went and changed the Locale ID on the VersionInfo page to be English(United Kingdom) and rebuilt and ran the app, and the version info was displayed correctly.
I’d be curious to know if you repeat the above steps does everything work, or do you get the same issue.
Ray
Hi,
Thank you for reporting this. There is definitely an issue with the new KSVC GetIt package that Embarcadero created for 10.3. You are correct, the RaizeComponentsVcl.a file is missing from the Lib\RX10.3\Win64 directory.
I would strongly recommend that you report this to Embarcadero so that they can fix it for the next release (or in an update).
In the meantime, you can rebuild the component packages (including the RaizeComponentsVcl.a file) using the !Build_RC6.cmd file located in the Source subdirectory. Unfortunately, the version of the !Build_RC6.cmd file that was included in the latest version of KSVC is not up to date. You can download an updated version from the following link. https://raize.com/wp-content/uploads/Build_RC6.zip
After downloading, unzip the contents and replace the !Build_RC6.cmd file in the C:\Users\Public\Documents\Embarcadero\Studio\20.0\CatalogRepository\KonopkaControls-260-6.2.3\Source directory with this new version. You will need to edit the command file to make sure that the path to the 10.3 compiler is correct for your machine. The command file will only display a message until you edit the file and uncomment a particular line to allow the build process to continue.
Once you follow the instructions for editing the file, open a Command Prompt (we recommend opening it As an Administrator). Then you MUST navigate to the C:\Users\Public\Documents\Embarcadero\Studio\20.0\CatalogRepository\KonopkaControls-260-6.2.3\Source directory, and then you can execute the !Build_RC6.cmd file. This will rebuild the components and packages and when it is complete, you will find the RaizeComponentsVcl.a file located in the Lib\RX10.3\Win64 directory.
Ray
Hi
There are actually two version numbers available in the VersionInfo block: ProductVersion and FileVersion. I suspect that you have the ProductVersion set but are querying the FileVersion.
Ray
Hi Matthias,
That behavior is by design. To allow editing of the value with the keyboard, you need to set the AllowKeyEdit property to True.
Ray
The TRzCalendar component does allow you to customize the colors when the control’s ThemeAware property is set to False. However, that property is not accessible in the TRzDateTimeEdit control (it probably should be).
As for changing the size of the dropdown, you can do that by change the PopupWidth and PopupHeight property values. Please note that both property values must be changed in order for the resize to occur.
Ray
Unfortunately, the appearance of the combo box is controlled by the visual style of the control via Windows. The control does change its appearance if VCL Styles are used because the VCL Style defines a new style for the elements of the combo box. So, if you are using VCL Styles, then you could get a custom looking combo box. It would be nice if you could apply a VCL Style to jus a single control, but that is not possible.
Ray
Hi Barry,
I apologize for not replying to your messages when you originally posted them, but thank you for sharing your results. I’m glad you got it working.
Ray
The button appearance is thanks to Microsoft and the way csDropDownList combo boxes are displayed on Windows 7. Thankfully, they changed the appearance for Windows 8 and 10, but that does not help you. (Although you probably should upgrade Windows soon).
Anyway, setting the Style to csDropDown and setting the AllowEdit property to True is the recommended alternative. The AllowEdit property does NOT prevent the user from typing into the control, but it does prevent the user from entering in text that does not appear in the drop down list. This way, the incremental searching functionality still works in the control, but the user cannot enter in a new value that is not in the drop down list.
Ray
Hi,
I am unable to duplicate the behavior you are describing. Can you describe the exact steps that you are taking to reproduce the issue?Ray
Hi,
In general the CodeSite Tools installer should not require a restart. However, a couple things come to mind. First, does the restart prompt occur for all users, or just some users? Also, is your main installer being executed with Administrator rights? The CS4 Tools installer does try to update keys in the Registry in the HKEY_LOCAL_MACHINE hive. Also, was CodeSite previously installed on the machines causing the issue? It’s possible that Dispatcher may have already been installed on the machine. The current CodeSite Tools installer does check if any of the tools are currently running and shuts them down. However, the current version is CS5, not CS4. I believe this functionality was added to CS4, but I don’t recall the exact version. Is there are particular reason you are using CodeSite 4 instead of CodeSite 5?
Ray
Hi
We apologize for the inconvenience for the missing help file. It will be fixed in the next update. In the meantime, you can download the help file from the following link:
https://raize.com/wp-content/uploads/CodeSite5Help.zip
After downloading the zip file, unzip the contents and copy the CodeSite5.chm file to the CS5\Help directory where you installed CodeSite (e.g. C:\Program Files (x86)\Raize\CS5\Help). This will allow the Help file to open from the Delphi Tools > CodeSite menu and from each of the CodeSite applications (e.g. Live Viewer, Dispatcher).
Ray
Thanks for sending the file. I am able to duplicate the behavior you reported. I’ve seen customers log some pretty long strings into CodeSite, but nothing comes close to the amount of data that you are trying to log. The delay in the viewer is resulting from all that data being loaded into the inspector pane.
We can consider addressing this condition, but I must ask, why are you logging so much data into a single message? How are you expecting to use this logging information?
Ray
Hi
How exactly are you sending the long string value to CodeSite? Is it a simple statement such as:
CodeSite.Send( 'SampleString', SampleString );where SampleString is of type string? And just how long is the string that you are logging?
Also, when you state “when I go to that entry”, what exactly do you mean by that? Are you hovering over the message in the message list and the hint window is popping up? Or, are you clicking on the message? And, do you have the Inspector Pane visible?
Do you have a sample log file that illustrates the issue that you could send to me? If so, please zip up the log file and send it to our support email address.
Ray
Hi Warren,
I am sorry to hear that you are having challenges with utilizing CodeSite for your products, but I do value your feedback. There are certainly limitations to the way CodeSite is currently designed with respect to services. This wasn’t always the case, but the fact is that logging from services with the current version of CodeSite is challenging because of the increased isolation that Microsoft has added to Windows.
When it comes to using CodeSite in a service, it all comes down to deciding how to run the CodeSite Dispatcher. There are two choices: 1. run the Dispatcher as a service, 2. run the Dispatcher as a desktop app. While it may appear that only option 1 is valid, but this not necessarily true. Each option has its advantages and disadvantages.
Running the Dispatcher as a service does make it a little easier for the CodeSite logging classes to communicate with the Dispatcher because the default transport method (wm_CopyData) can be used. Also, the Dispatcher service can be running even when no user is logged into the system. However, with the Dispatcher running in the service window station it is NOT possible to do Live Logging with the Dispatcher running as a service. That is because Windows prevents the Dispatcher from transporting CodeSite messages to the Live Viewer running on user’s desktop.
Running the Dispatcher as a desktop application will allow you to conduct Live Logging even from service apps. However, in order to do this, the transport method the CodeSite logging classes use to send their messages to the Dispatcher must be changed from wm_CopyData to TCP. This is accomplished by calling the ConnectUsingTcp() method either on the CodeSiteManager, or on the individual TCodeSiteLogger objects in your app. TCP messages are allowed to cross window station boundaries and thus the CodeSite Dispatcher will be able to receive CodeSite messages and then dispatch them to the Live Viewer and of course log files. Of course, in order for the Dispatcher to receive the TCP CodeSite messages, the appropriate port must be opened. Some customers have run into challenges in getting ports opened in a production environment for “logging”.
The reality is that in today’s environments, logging from services really is best served with the ability to allow the service itself to be able to log CodeSite messages directly to an isolated log file without requiring coordination from an external application. It should still be possible to send CodeSite message remotely, if desired, but again, it should all be handled within the service itself. This is, in fact, one of the major design goals I have been using while working on the next major release of CodeSite. I wish I could provide more concrete info and a release date, but I’m not ready to do that just yet.
In regards to item 3 in your list, I am intrigued by your comments. The Live Viewer has always been the primary developer tool for “debugging”. It was never intended to be used as a kind of CodeSite dashboard. But perhaps a CodeSite Dashboard is something that you would be interested in? I suppose a “Dashboard” mode could be added to the Live Viewer, but I’m wondering if it would be better to have a dedicated app. I am interested in learning more about how you are logging on non-developer machines. The Live Viewer is included in the CodeSite Tools as a convenience for on-demand Troubleshooting and not the usual method for capturing logging data–most end users do NOT want to see a logging window. Are you conducting File Logging along with Live Logging in your apps?
In regards to item 4, it is possible to send CodeSite messages to remote computers. This involves setting the CodeSiteManager.DefaultDestination or the Destination property of an individual CodeSite logger. The CodeSite Help does provide information on how to setup the subproperties of the destination properties. The key is that the CodeSite Dispatcher needs to be running on the local machine AND the remote machine.
I hope this helps answer some of your questions and concerns, and thanks again for your feedback.
Ray
