[Ray Konopka]

Hi,

Thank you for the additional information. I have researched this issue some more, and I have discovered that the InnoSetup script that is used for CodeSite Tools installer does make use of the SWbemLocator to determine if any of the CodeSite Tools applications are currently running. The approach appears to be a pretty common practice with InnoSetups scripts. What is surprising is that WMI is not available on some of your customer’s computers. This particular module is the CodeSite Tools setup has been present for quite some time, and we’ve never received any reports such as this.

I’m looking into alternative methods to using the SWbemLocator and if that is not possible, coming up with a way to gracefully handle the situation that SWbemLocator is not found and still continue with the installer.

Ray

[Ray Konopka]

Hi,

We are not aware of any issues with the CodeSite Tools installer. However, in 5.3.3 the CodeSite Tools installer was changed to InnoSetup. The old installer was built with Wise Installation System.

Is the CS5_Tools.exe installer being run separately? Or, it is being launched from within your own product installer? Are you specifying any parameters to the CS5_Tools.exe program?

What type of machines are you running the installer on? From the message, it appears that InnoSetup may require WMI.

Does this error happen all the time? Or, just a certain machines?

Ray

[Ray Konopka]

Hi Ulrich,

To be honest, I had hoped that CodeSite 6 would be released by now. I had demonstrated many of the new features of CodeSite 6 at EKON and ITDevCon last fall. Unfortunately, like many of you, CodeSite’s tools were impacted by limitations in the KSVC. I hope to have more to say about this soon. I do apologize for being so vague.

Ray

[Ray Konopka]

Hi Csaba,

I already answered same question via email. I’m including response below in case others are interested.

—
One option is to use the CSFileExporter.exe tool that is included with CodeSite (including the Express edition). It is located in the CS5\Bin directory (typically, C:\Program Files (x86)\Raize\CS5\Bin). It is a command line tool that allows you to export messages from a CodeSite log file into a different format (i.e. XML, TXT, CSV).

The one downside to using the CSFileExporter is that you have to manually run it to export the data. One of the requests that we have been getting a lot recently is to provide a means by which CodeSite log data could be ingested into an aggregate system such as Splunk. As a result, in CodeSite 6, we are introducing a new destination type called a Digest that contains CodeSite messages in plain text, formatted for easy ingestion in to Splunk and other aggregate logging systems. Unfortunately, CodeSite 6 has not yet been released.

Another option is to utilize the OnSendMsg event available in CodeSite Studio to write out to a text file for each CodeSite message. The message data is included in the event handler. The downside to this is that you have to have CodeSite Studio and you have to write out the log file manually.

Of course, the Digest option in CodeSite 6 will be the best solution once it is released.

Ray

[Ray Konopka]

For those following this thread. Jeremy did send me a sample project and I am able to duplicate the issue. I am working on a fix.

Ray

[Ray Konopka]

Hi Jeremy,
Unfortunately, I’ve been unable to duplicate the problem. Would you be able to send the source code to a sample project (no exes) to support@raize.com that demonstrates the issue?
Ray

[Ray Konopka]

Hi,
I’m not sure I completely understand your question. Let me try to rephrase what I think you are asking. Consider a TRzPanel component on a form and inside that panel are other controls such as a TRzButton or TRzEdit. Then when you set the Enabled property of the TRzPanel to False, the Enabled property of the button and edit are also changed to False. And you are asking if that behavior can be disabled? Is that correct?

This behavior is by design and cannot be changed without modifying the source code of the component. The reason the TRzPanel operates in this manner is because if you set up the form in the same way but use a TPanel instead of a TRzPanel, when you disable the panel, the button and edit inside the panel do not allow any user interaction, but the controls still appears as though they do allow interaction.

Also note that the TRzPanel also keeps track if any its controls are already disabled when the panel is disabled. And then when the panel is re-enabled, those originally disabled controls remain disabled.

Ray

[Ray Konopka]

Unfortunately, Embarcadero has been working through some technical issues with some of their servers (including GetIt). Hopefully, things will be working better soon.

Ray

[Ray Konopka]

Hi Steve,

The TRzRichEdit does not provide any direct support for links. The TRzRichEdit inherits much of its functionality from TRichEdit but provides Custom Framing support to match other controls. However, since TRzRichEdit is a direct descendant of TRichEdit, techniques for adding links to TRichEdit should also work for TRzRichEdit. Here is a stack overflow topic that talks about ways to do that:
https://stackoverflow.com/questions/42532760/adding-true-hyperlink-support-to-trichedit

Hope this helps,
Ray

[Ray Konopka]

Hi Leonardo,

The TRzBitBtn is a windowed control and by design captures the input focus. If you do not want to capture the focus, you can use a TRzToolButton instead, which is a graphic control and does not capture the input focus. That’s why it works well for toolbars. You can change the ShowCaption property to True and then make it work like a TRzBitBtn (except it doesn’t change the focus).

Ray

[Ray Konopka]

Hi,

The CodeSitePlugIns.dcp file is located in the …Raize\CS5\Lib\RX10.2\Win32 directory. You may need to edit the BuildPlugIn.cmd file and update the CodeSiteInstallDir variable with the path to where you installed CodeSite Studio on your system.

Ah, are you using CodeSite Express? The CodeSitePlugIns.dcp file is only available in the Studio Edition.

Ray

[Ray Konopka]

Hi,

You can download the sample plug-in from the following link:

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

Inside the zip file you will find several files related to the plug-in and several files that are for a test program that generates a couple CodeSite messages.

As noted earlier, you will need to have Delphi 10.2 Tokyo to rebuild the custom plugin. However, I did include the CSDecodeTextPlugIn.bpl in the zip file. Copy this BPL file to the Raize\CS5\Bin\PlugIns directory of your CodeSite 5 installation. (e.g. C:\Program Files (x86)\Raize\CS5\Bin\PlugIns. Restart the Live Viewer so the viewer can pickup the new plugin during startup.

The custom plugin related files all start with CSDecodeText*.
CSDecodeTextInspector.pas is the main inspector unit, which overrides several simple methods including the CreateInspectorControl method, which is used to instantiate and instance of the TfrmDecodeText form.
CSDecodeTextForm.pas (and .dfm): the inspector form used to display the decoded data.
CSDecodeTextPlugIn.dpk is the basic package for the plugin
CSDecodeTextPlugIn.verinfo – version info resource file
CSDecodeTextPlugInResources.rc – resource file that links in version info

There are also two command files for building the resource files and compiling the plugin.

Ray

[Ray Konopka]

Hi,

I have created a sample plugin that decodes a CodeSite message where the message text has been encoded in Base64 — basically the first part of handling encrypted message text. I’ll post the code as soon as I can — sometime tomorrow.

In the meantime, please note that in order to build a custom plugin for CodeSite 5, you must use Delphi 10.2 Tokyo.

Ray

[Ray Konopka]

Hi Andrea,
When a program first tries to send a CodeSite message, the CodeSite logging class (TCodeSiteLogger) checks to see if the Dispatcher is running. If it is not, then the Dispatcher is started. The logger class looks in the Registry for the location of the CodeSite Dispatcher in case the CodeSite Tools are installed on the computer. If the Registry entry is present, the Dispatcher at that location is launched. If the Registry entry is not present, then the logger will look in the current directory of the application and launch the CSDispatcher.exe file if it is present.

Having the Dispatcher get started by an application is quite common and I do that all the time. I’m curious to learn more about your attempts and what type of application you are building and how you are using CodeSite Express. Feel free to send an email to support@raize.com and I’ll be happy to assist in tracking down the issues.

Ray

[Ray Konopka]

Hi David,

The GUID that is displayed in the message represents a DispatchID. In CodeSite 5 (and earlier) when you first send a message to the Dispatcher, a Register Dispatch ID message is sent first and the Dispatcher registers the Dispatch ID with the destination details currently defined and this in turn specifies which Transporter should be used. Therefore, for future messages that include the Dispatch ID, the Dispatcher knows where to route the messages to.

The error messages are showing up in the Dispatcher Log every time the Dispatcher receives a CodeSite message referencing a Dispatch ID that the Dispatcher does not know about. Restarting the application that is generating the CodeSite log messages should stop the error message because a new Dispatch ID will get generated.

The Dispatcher not being able to find a Transporter for a Dispatch ID should rarely happen. Even if the Dispatcher is closed, the current set of Dispatch IDs and Transporters are persisted to disk in the CSDispatchIDs.ini file. The situation can happen if the Dispatcher is forcibly terminated and the Dispatcher does not have a chance to save the Dispatch IDs.

Ray

[Author]

Posts