[Ray Konopka]

Ok. Interesting. The “For11.2” part is what I was looking for. I thought perhaps you had the previous version of KSVC 7 installed and that was causing the issue. I’m engaging Embarcadero to look into the GetIt package deployment so that they can fix it, since it is not an isolated issue.

Ray

[Ray Konopka]

Hi David,

I’m a little confused by what you are trying to accomplish given your example. When using the Launch method to launch another app, you have the choice to wait for the launched app to finished (WaitUntilFinished := True), which means that the call to Launch blocks and only returns when the launched app terminates. If WaitUntilFinished is set to False, the Launch method returns immediately and your app continues to run, *and* when the launched app terminates the OnFinished event is fired.
In your sample code, you are launching the secondary app and then trying to use a loop to essentially wait for the launched app to terminate. I would suggest writing an OnFinished event handler instead. If you need to update your UI while the launched app is running, for example to prevent the user from doing certain activities, you can set that up before calling Launch. Then when OnFinished is invoked, you can update the various flags so that the user will be able to continue.

Ray

[Ray Konopka]

Hi Allen,

I have some more information. I’ve been trying to determine why only a couple users are experiencing this issue. Then I remembered that Embarcadero silently released an 11.2 specific version of KSVC. I do not like the way all that was handled, but I believe this is what is affecting your installation.
So, would you please check the installation directory of KSVC. Please navigate to:
C:\Users\Public\Documents\Embarcadero\Studio\22.0\CatalogRepository
and then please reply with the name of the KonopkaControls directory.

Ray

[Ray Konopka]

Hi Allen,

You are the second person who has reported this issue. We thought it was isolated to the other developers installation, but since you are also experiencing this same issue, we now believe there is a problem with the GetIt deployment of KSVC. We will be contacting Embarcadero to look into this, but I also suggest you also report this issue to Embarcadero.

In the meantime, you can work around the issue by adding the KSVC Source directory to your project’s Search Path and compile your project. The DCU file that is cause the issue is actually the RzBorder.dcu. The RzPanel.pas unit uses the RzBorder unit. Apparently, there is something wrong with the RzBorder.dcu in the GetIt deployment. Once you compile the project and get an updated RzBorder.dcu file, you can copy the RzBorder.dcu file to the Lib\Win32 directory and then remove the Source directory from the Source path. Then things should compile properly.

Also note that if you are also going to be building 64-bit apps, you’ll need to do the same thing and move the 64-bit version of the RzBorder.dcu to the Lib\Win64 directory.

Ray

[Ray Konopka]

Hi Peter,

Did you fill out the other MRU related properties (i.e. MruID, MruSection, and MruRegIniFile) as described in the help? MruPath is the old way to specifying the Registry path, it is recommended to use the mruRegIniFile property.

The LoadMRUData method is used to force a reload of the combo box with the list of most-recently-used items from its persistent storage defined by the MruRegIniFile, MruSection, and MruID properties, but in practice should rarely need to be used. The list will get saved and loaded automatically.

Ray

[Ray Konopka]

Hi,
Thanks for explaining how you are using the MaxParts and other values. Given that the primary objective is to determine optimal values for the properties, I believe it would be helpful to instruct the testing team to clear out the log files after changing the values and then re-evaluate the sizing. This would eliminate the unwanted behavior that can occur when reducing the MaxParts values when there are already more parts in the directory.

Ray

[Ray Konopka]

Hi Ariagna,

I’m a little surprised by your statement, “no error is generated but [if] it stops my application because it continues trying to access the destination.” First, I’m assuming that the “if” was a mistake. Second, when using Remote Destinations, the typical approach is that the logger packages up the message and then sends it to the Local Dispatcher, and the Local Dispatcher sends it to the Remote Dispatcher running on the remote machine. In this case, the connection error actually occurs in the Local Dispatcher. You can see this because an error message will be recorded in the Dispatcher Log. However, the error does not stop your application.
Now, if you are bypassing the local Dispatcher and using the ConnectUsingTcp method to connect directly to a remote CodeSite Dispatcher, then if the remote dispatcher is not running, your the call to the CodeSite Send method will be blocked while trying to establish a connection to the remote dispatcher. However, in this case, an exception is raised in your app, which is one of the reason why we generally do not recommend using ConnectUsingTcp for this purpose. It was added to address another situation.
Anyway, there are a few things to consider when performing remote logging. First, you may wish to consider running the remote Dispatcher as a service, so that it cannot be easily shutdown. Another thing to consider is to also record your CodeSite messages to a local log file (in addition to the remote destination) because in the event of a network outage and the remote connection, the local log file will still be saved.
Getting back to your question if there exists a way to set a timer for accessing the destination. When using the typical process of Local Dispatcher to Remote Dispatcher, there is no function like this available because the actually remote transport is handled in the CodeSite Dispatcher executable. As for the ConnectUsingTcp approach, there is no timeout property surfaced, but the TCP message transport is made using the Indy components (e.g. TIdTcpClient), and it would be possible to set the connection timeout for the FTcpClient component in the TCodeSiteTcpConnection.ConnectToDispatcher method. However, this would require modifying the source Code.

Ray

[Ray Konopka]

Hi,

Thank you for posting the additional details and clarifications. I am able to duplicate the behavior that you reported. The crux of the issue is that the Dispatcher looks in the specified folder for all log file parts, and ends up selecting the “last” part file. The assumption is that the last part file in the directory is either the MaxParts log file or an earlier log file part. So the last part file is selected and checked for MaxSize. If the file exceeds MaxSize, then the next part number is calculated from the “last” part file.

The problem is that the assumption above is incorrect in the situation that you describe. The “last” log file represents a log file part that already exceeds MaxParts, which is why the parts increase. Well, the part files increase until the number of digits needed to represent the parts changes to a new order of magnitude. For example, in Sample 1, the parts increase to 7, 8, 9, and then at 10 the file size just grows forever. In Sample 2, the parts increase to 13, 14, 15, etc. all the way to 98, 99. Then at 100 the file size just grows forever.

Part of the fix for this is to NOT use the “last” part file name if it exceeds the MaxParts value. However, this is fine if the MaxParts value does not cross a power of 10 value. For example, in Sample 1, MaxParts went from 6 to 3. No problem. However, for Sample 2, MaxParts changes from 12 to 8, which crosses 10. The problem is that the file parts are named differently when MaxParts is set to 12 versus 8. When MaxParts is set to 12, the file parts will have names like:
Sample_01.csl
Sample_02.csl
. . .
Sample_12.csl

However, with MaxParts set to 8, the file parts will have names such as:
Sample_1.csl
Sample_2.csl
Sample_8.csl

The fact that the format of the log file parts is different makes recovering from this situation rather complicated. There are a couple ways in which this could be handled. First, the code that looks for the “last” part needs to be more specific about finding a match and consider the difference between the two cases above. So, in Sample 2 when the MaxParts is 8, the code would look for Sample_1, etc. and NOT consider Sample_01 as a matching part. In this case, after switching MaxParts from 12 to 8, the log file parts would essentially start over at Sample_1.csl, and the existing Sample_01.csl to Sample_12.csl files would remain unchanged and be there forever, even after the “new” Sample_1.csl to Sample_8.csl files get rotated out.

The second method of handling things would be to change the way the log file parts are named and simply use 4 digits for all log file parts. So, the file names would look like:
Sample_0001.csl
Sample_0002.csl
. . .
Sample_0012.csl

This is the solution that I am leaning towards, but I’m not sure it makes sense to do this for CodeSite 5 because of the implications it would have on existing deployments. Essentially, all log file parts would reset to *_0001.csl, which is no different than the problem I described earlier.

This type of change is more likely for CodeSite 6, when there are more significant changes in the product and how destinations are managed, and resetting log file parts for an application would be more easily facilitated during an upgrade.

With all of this in mind, I am curious to gain a better understanding of how you are using the MaxParts property. Specifically, is the MaxParts property something that gets changed a lot for your application? What is the process that results in the property value changing? Do you provide access to change this on an end user machine, or is it simply set internally by you (i.e. developer)? How often does the value change?

In all the years that CodeSite has supported log file parts, this issue has never been reported. I suspect because the MaxParts value is typically not changed (at least not decreased), and if the property is changed, the existing log file parts are simply deleted when deploying the application. Hence, I am curious to understand the implication of this particular issue on your deployment.

Ray

[Ray Konopka]

Hi,
For issue 1, is it correct to assume that with the MaxSize=40 and MaxParts=6 that before you change the MaxParts to 3, you have 6 log files that already exist in the directory, and then you start doing file logging with the new MaxParts value of 3? I’m trying to understand the sequence of steps so that I can try to reproduce. And please confirm that all you changed was the MaxParts value to 3–that is, you did not change any other properties.

In regards to Issue 2, you state “new log files are also generated on top of the existing ones.” Can you be more specific about what exactly you are seeing in this situation?

Also, your comment “no file should exceed the size limit set by the MaxSize whatsoever” is not valid. Since each CodeSite message is variable in size, it is possible that the last message saved to a log file part will result in the log file part being larger than the MaxSize value. The MaxSize value specifies whether or not the next CodeSite message is allowed to be added to the file. If the current log file part is less than MaxSize, then the message is saved to the log file.

We considered looking at the size of the next message to be saved, and then only save to the current log file part if the resulting size will be less than MaxSize. However, then you need to consider what happens if the next message is larger than MaxSize, which can happen with screenshots, for example. Then you end up with a log file part larger than MaxSize anyway, because you have save the message is the log file part. We did not see the benefit outweighing the added complexity.

Ray

[Ray Konopka]

Hi Ariagna,

The software is distributed via a download link, but once you download it onto a computer (obviously with internet access), you can copy the installer to the desired computer and run it from there. The installer does not require internet access.

Ray

[Ray Konopka]

Hi Paul,

Thank you for sharing how you were able to resolve the issue with the GetIt Package Manager download.

Ray

[Ray Konopka]

The csmDataSet message constant is defined in the CodeSiteDBTools unit. That unit also defines the CodeSite custom formatters for sending TDataSet and TDataSetRecord values. However, as Rich mentioned, the CodeSiteDBTools unit is available in the CodeSite Studio edition and not CodeSite Express.

Ray

[Ray Konopka]

Very good. One little tip: if you first select the message that matches the criteria you are interested in (e.g. Thread), and then invoke the New View dialog box, the various fields will be pre-populated with the values of the selected message. Makes it much faster to select your desired criteria.

Ray

[Ray Konopka]

Hi Paul,

I am sorry to hear you are having issues with the GetIt Package Manager. Unfortunately, we have no control over that, and I would suggest that you contact Embarcadero.

Ray

[Ray Konopka]

Hi Ariagna,

There is no separate manual, but the CodeSite Help has a lot of information about the product. You can get to the Help file from the Help menu of any of the CodeSite Tools (e.g. CodeSite Live Viewer). You can also get to the CodeSite Help file from within the RAD Studio IDE by selecting the Tools > CodeSite > CodeSite Help menu item.

In regards to your other question about “CodeSite Studio is planned to be applied at the server level”, I’m not sure I completely understand your intention. However, I can say that each CodeSite message contains the name of the Computer from which the message originated.

Ray

[Author]

Posts