[Ray Konopka]

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

[Ray Konopka]

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

[Ray Konopka]

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

[Ray Konopka]

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

[Ray Konopka]

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

[Ray Konopka]

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

[Ray Konopka]

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

[Ray Konopka]

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

[Ray Konopka]

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

[Ray Konopka]

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

[Ray Konopka]

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

[Ray Konopka]

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

[Ray Konopka]

The SendList method is designed to handle generic TList instances. For example,

uses
System.Generics.Collections;

procedure TForm12.RzButton1Click(Sender: TObject);
var
  IntList: TList<Integer>;
begin
  IntList := TList<Integer>.Create;
  IntList.Add( 14 );
  IntList.Add( 23 );
  IntList.Add( 58 );
  CodeSite.SendList<Integer>( 'Generic List', IntList );
end;

Hope this helps.
Ray

[Ray Konopka]

Hi,
The current release of CodeSite supports 32-bit and 64-bit for Delphi targets. The Raize.CodeSiteLogging.dll assembly is compiled with the v4.0.30319 .NET Framework C# compiler, and the assembly’s ProcessorArchitecture if MSIL.

With respect to Windows Services, the default transport method needs to be changed because of restrictions Microsoft has added to services. Details are outlined in the CodeSite Help.

Ray

[Ray Konopka]

Hi Warren,

Sending CodeSite messages from service apps is a bit tricky because of 2 reasons. The first is the communication restriction that Microsoft has placed between window stations. And the second is the communication method that CodeSite uses to send messages.

When you are trying to send CodeSite messages from a service app, you have two choices. The first is to change the communication method that the CodeSite Logger classes use to send messages to the CodeSite Dispatcher. The default method uses wm_CopyData window messages. However, window messages are no longer allowed to be sent across window stations. Therefore, you can switch the method to use TCP. To do this, you need to call the ConnectUsingTcp() method on the CodeSiteManager (or on an individual logger instance). The logger classes will then use TCP to send the CodeSite messages to the Dispatcher, which is presumably running on the currently logged in users desktop (window station). In this case, Live Logging will continue to work because the Dispatcher will be able to send wm_CopyData window messages to the CodeSite Live Viewer (also running on the desktop).

The other way of using CodeSite in a service application is to actually run the CodeSite Dispatcher as a service. In this case, the Dispatcher is running in the same window station as the service app and the wm_CopyData messages will get through from the logging classes to the Dispatcher. This arrangement is typically used when you need to log information from the service app and there is no active user and no user desktop. Furthermore, in this arrangement, you can really only send CodeSite messages to a log file and not the Live Viewer. The reason Live Logging does not work, is related to the information described above. The Dispatcher is running in the Service space and the Live Viewer is running (if it is running) in a user’s desktop station. The Dispatcher uses wm_CopyData to send messages to the Live Viewer–and unlike the Logging Classes to Dispatcher communication which can be changed to TCP, the Dispatcher to Live Viewer communication cannot.

So, I hope the above helps clarify things for you. If you do not need to run the Dispatcher as a service, (as described above), then I would run it as a normal app and then just call the ConnectUsingTcp method on the CodeSiteManager inside your service app code (before trying to send any CodeSite messages), and then you should be able to see your CodeSite messages appear in the Live Viewer.

Ray

[Author]

Posts