[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

[Ray Konopka]

Hi,
I apologize for the delay in responding. One thing to consider when dealing with user access is that it may be better to simply hide the controls that are not applicable to the current user’s access.

However, given your question about deleting buttons from a TRzToolbar, you can accomplish this by simply freeing the toolbar controls. For example,

var
  I: Integer;
begin
  for I := RzToolbar1.ControlCount - 1 downto 0 do
    RzToolbar1.Controls[ I ].Free;

Ray

[Ray Konopka]

Hi Steve,
Forgot to respond when you originally posted. I will add this feature request to our list.

Ray

[Ray Konopka]

Hi Nina,

I believe that all Delphi and C++Builder users are able to download the Konopka Signature VCL Controls (formerly Raize Components) from the GetIt package manager.

Ray

[Ray Konopka]

Hi Gary,

The help should be accessible from within RIO by pressing F1 with a component selected. You can also manually get to the help file and the demo directory by navigating to the installation folder.

For 10.2 (Tokyo) and earlier, the components are installed into C:\Program Files (x86)\Raize\RC6. However, for 10.3 (Rio), Embarcadero created a custom GetIt Installer for the components. They are no longer installed in their usual location. Instead, they are installed in: C:\Users\Public\Documents\Embarcadero\Studio\20.0\CatalogRepository\KonopkaControls-260-6.2.3

Ray

[Ray Konopka]

Hi,

I’m not sure I understand what you are trying to accomplish. The TRzMenuButton does not have concept of selection (hence no ItemIndex property). The intent of the button is to present a popup menu when the user clicks the button. The user then selects the desired menu item from the popup menu.

Ray

[Ray Konopka]

Hi Chris,
I apologize for the delay in responding. Apparently, I had mistakenly marked all posts as read and did not realize I did not respond to your message.

The TRzDBGrid does indeed descend from the TCustomDBGrid component so that it does inherit basic functionality from the ancestor control.

As for adding touch support, I would suggest taking a look at the gesture support included in Delphi. That way you could leverage scrolling without having to interact with the scroll bar itself.

Ray

[Ray Konopka]

The TRzStatusBar uses the standard alignment functionality built into the VCL. In older versions of Delphi, at design-time, there used to be situations where the actual position of the control can change if its left (or top) edge overlaps the left (or top) edge of another control as a result of the bounding size of the parent control changes to become too small.

However, I don’t believe this is still true for more recent versions of Delphi. Is your app doing anything in code to position the controls, set constraints, restore form size, etc?

I’ve tried to duplicate what you are describing, but so far I have not been able to.

Ray

[Ray Konopka]

Transparency in VCL controls that have a window handle (as opposed to TGraphicControl descendants) is handled by the control painting the parent window’s background into the control’s client area. So, the panel is behaving as designed.

I’m not entirely sure what you are expecting a ReadOnly shell list to do, or not to do? From your description you might want to try setting the Enabled property to False, and then change the DisabledColor property to clWindow if you want it to appear active.

Ray

[Ray Konopka]

Hi,

From your description, you have a TRzPanel with Align := alTop and a TRzDBGrid with Align := alClient. Correct?

On the TRzPanel you have placed a series of buttons and combo boxes so that they are positioned vertically centered in the panel. There is no Align property setting to force the controls to be positioned vertically centered in the panel. Therefore, I am assuming that you have simply placed the controls where you would like them. Is this also correct?

I have created a test project with a TRzPanel and TRzDBGrid with their Align properties set as described above and I have not been able to duplicate the effect you are describing. I suspect that you have other settings or configurations that are resulting in the behavior you are seeing.

Are you able to duplicate the overlapping in a new test project with just a TRzPanel and TRzDBGrid? If so, please send the source code (no exes) to support@raize.com and I’ll take a look.

Ray

[Ray Konopka]

Hi Carl,
By disconnecting from the CodeSiteManager, I mean that if you change the CodeSiteManager.DefaultDestination then the logger instance will not use any of those changes.

Setting the CodeSiteManager.DefaultDestination to the new TCodeSiteDestination instance will result in all logger instances using the same destination information.

To log your CodeSite messages to just a log file, you simply create a TCodeSiteDestination instance and only activate the LogFile destination sub-type. An example of this is shown in the Getting Started section of the CodeSite Help.

Ray

[Ray Konopka]

Hi Carl,
Glad you have it working again. I do have a couple comments regarding the code you posted. In your code, you are creating a new Destination object and you are assigning it to both the CodeSite global logger and the CodeSiteManager. By default, each logger instance uses the destination that is defined in the CodeSiteManager. This happens when the logger’s Destination property is nil. By assigning the CodeSite.Destination to a new TCodeSiteDestination instance, you are disconnecting it from the CodeSiteManager.

Ray

[Author]

Posts