[Ray Konopka]

Hi David,

You are correct, not much was done with KSVC in 11.3, and I keep getting more reports of changes that were made (or should I say started) that were not completed and more significantly break other functionality.

As you noted in your original post in this topic, everyone should please continue to keep voting and submitting Quality Portal reports for all issues found. Prefix all reports with “KSVC:” (as requested by Marco Cantu). And yes, I completely agree that it is ridiculous to have to vote to get bugs fixed.

Ray

[Ray Konopka]

So, the TRzSizePanel is technically working as designed. The TRzCustomSizePanel.GetParentWorkingRect method looks at the various controls (and child controls) on the form to determine the range of the sizing bar. In your particular example, the right edge of the Close button is restricting the range of the right SizePanel.

If you were building an SDI application, then I would suggest dropping a Panel into the main client area, setting the Align property to alClient, and then dropping your panel with the Close button onto the client panel and set the Align property to alTop. Then the size panel would function as you expect. However, that approach does not work with an MDI application.

As an alternative, you could align your close panel to be alTop, which would allow the size panel to work properly, but then you do not get the visual layout you are looking for.

Another option would be to modify the TRzCustomSizePanel.GetParentWorkingRect method and comment out the alCustom case label in the middle of the method. This would eliminate the range check for the alCustom panel and then the size panel would be able to be dragged over the sub-panel.

Ray

[Ray Konopka]

Unfortunately, the animated GIF is not animating, so I’m not sure what behavior you are seeing. As for debugging the components, you can add the source directory for the components to your Project Search Path. Then when you rebuild your project, the KSVC source will get recompiled as well and then you’ll be able to step through the code.

Ray

[Ray Konopka]

Hi,

Your best bet would be to change the BlinkIntervalOn value in code (in the FormCreate event handler for the desired form) to prevent the DFM files of the other forms using TRzLabel or TRzStatusPane from getting updated.

Ray

[Ray Konopka]

Hi Nathan,

You are disabling the Dispatcher correctly. When the dispatcher is disabled, CodeSite messages generated from your applications are still sent to the Dispatcher, but the Dispatcher will not forward them onto their destination. The other way to “disable” logging is to set the Enabled property of the CodeSiteManager (or individual CodeSite logger objects) to False in your application.

As for the Out of Memory errors that you are receiving, what version of the CodeSite Dispatcher are you using? Are you running the latest version?

Ray

[Ray Konopka]

Hi Bob,

Originally, the SendCollection did exist, but was eventually replaced with an overloaded Send method that accepts a TCollection parameter. Clearly you found a gap in the documentation. I’ll be sure to fix that for the next release. I apologize for the confusion.

Ray

[Ray Konopka]

Hi Gabriel,

The blinking support in the TRzLabel and TRzStatusPane utilizes a common control list that wraps a TTimer that controls the blinking on and off. There are two primary reasons why this was done. First, only one timer is needed instead of having a separate timer for each label. Second, it allows all labels that are blinking to blink at the same rate and more importantly that the blinking is synchronized.

To use a different blinking interval for a label on a separate form, then I would suggest dropping a TTimer on the form and manually blink the desired label by changing the color.

Ray

[Ray Konopka]

Hi Harald,

The easiest solution is to upgrade your Delphi 11.2 version to 11.3. After doing so you will then download the KSVC from GetIt, which is built for 11.3.

If you need to stay with 11.2, then you have a couple options. You could try running the !Build_RC6.cmd file that is located in the KSVC Source directory. You’ll need to follow the instructions at the top of the batch file to verify the Delphi version and compiler location. After editing the !Build_RC6.cmd file, you can then run it to rebuild the components using the Delphi compiler installed on your computer. The batch file will then copy the new *.DCU files to the correct location.

Another option is to add the KSVC Source directory to your Library Search Path (or Project Search Path) so that the compiler rebuilds the component source code. Then, when you build your project, the KSVC components will get recompiled.

The crux of the problem with 11.2 is that there is something wrong with the GetIt distribution that Embarcadero created for KSVC for 11.2. Specifically, one or more DCUs file distributed with KSVC for 11.2 are corrupted in some way. I am aware of the RzBorder.dcu file, but there could be others.

Ray

[Ray Konopka]

Hi Ariagna,

The key to handling this situation is to add a Reset Separator to the message log. In the situation that you described above, after forcibly terminating your app with Task Manager, go to the Live Viewer and select Edit > Add Reset Separator. (There is also a toolbar button that does the same thing). The reset separator appears as 2-line separator and resets the indentation level.

You can also programmatically add a reset separator by calling the AddResetSeparator method from a CodeSite logger.

Ray

[Ray Konopka]

Hi Marc,

Have you tried rebuilding with 11.3? There is also a new version of KSVC for 11.3 that was released.

Ray

[Ray Konopka]

Hi Andrew,
Sorry for the long delay. I missed your last response. The TRzFormState connects to a TRzRegIniFile which can save settings to either the Registry or an INI File.

Ray

[Ray Konopka]

Hi David,

I created test a project that I think may help explain things a bit. I dropped two TRzButton controls (btnLaunch and btnContinue) and a TRzLauncher onto the form. I also created a new enum called TAppState and created a corresponding private field, FAppState, to keep track of the current state of the app. The TRzLauncher has its FileName property set to ‘C:\Windows\Notepad.exe’. When the app starts, FAppState defaults to appInit. The btnLaunchClick event handler looks at the FAppState field and only launches Notepad if FAppState is not equal to appWaiting. Before calling RzLauncher1.Launch, FAppState is set to appWaiting.

The btnContinueClick event handler also looks at the FAppState field, but only calls ShowMessage if the state is appContinue. The FAppState field is set to appContinue in the OnFinished event handler.

When you start the app, clicking the Continue button does nothing since FAppState is appInit. Clicking the Launch button launches Notepad. While Notepad is running, clicking Launch or Continue does nothing. Once Notepad is closed, then clicking Continue will show the message box.

The point is that it is not necessary to do any looping to accomplish what you want. In fact, it is the looping (in the UI thread) that is forcing you to call Application.ProcessMessages.

Ray

unit Unit26;

interface

uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs, RzButton, RzLaunch, Vcl.StdCtrls, RzLabel;

type
  TAppState = ( appInit, appWaiting, appContinue );

  TForm26 = class(TForm)
    btnLaunch: TRzButton;
    RzLauncher1: TRzLauncher;
    btnContinue: TRzButton;
    procedure btnLaunchClick(Sender: TObject);
    procedure btnContinueClick(Sender: TObject);
    procedure RzLauncher1Finished(Sender: TObject);
  private
    { Private declarations }
    FAppState: TAppState;
  public
    { Public declarations }
  end;

var
  Form26: TForm26;

implementation

{$R *.dfm}

procedure TForm26.btnLaunchClick(Sender: TObject);
var
  J: integer;
begin
  if FAppState <> appWaiting then
  begin
    FAppState := appWaiting;
    RzLauncher1.Launch;
  end;
end;

procedure TForm26.btnContinueClick(Sender: TObject);
begin
  if FAppState = appContinue then
  begin
    ShowMessage( 'Allowed to Continue' );
  end;
end;

procedure TForm26.RzLauncher1Finished(Sender: TObject);
begin
  FAppState := appContinue;
end;

end.

[Ray Konopka]

Hi Andrew,

Since acquiring the components back in 2015, Embarcadero has addressed some HDPI-related issues in the components, but unfortunately there are still outstanding issues. Such as what you describe with TRzFormState. I would encourage you to submit a report on Quality Portal about this issue so that Embarcadero becomes aware of the issue and can track it, and hopefully address it. Please prefix the title of the report with “KSVC:” as request by Marco Cantu.

Ray

[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

[Author]

Posts