[Ray Konopka]

I apologize for the delay in responding. I did not realize you asked a follow-up question. Consider the following code. I have dropped a TRzComboBox, a TRzButton, and a TRzLabel onto a form.

procedure TForm29.FormCreate(Sender: TObject);
begin
  RzComboBox1.AddItemValue( 'Item One', '1' );
  RzComboBox1.AddItemValue( 'Item Two', '2' );
  RzComboBox1.AddItemValue( 'Item Three', '3' );
  RzComboBox1.AddItemValue( 'Item Four', '4' );
  RzComboBox1.AddItemValue( 'Item Five', '5' );
end;

The above code adds several items and values to the list. You can get the Values by using the Values list property. For example:

procedure TForm29.RzButton1Click(Sender: TObject);
begin
  RzLabel1.Caption := RzComboBox1.Values[ RzComboBox1.ItemIndex ];
end;

But the problem with this approach is that you need to protect against ItemIndex being -1, which will lead to an Index Out Of Bounds exception. A better approach is to simply use the Value property as shown below:

procedure TForm29.RzButton1Click(Sender: TObject);
begin
  RzLabel1.Caption := RzComboBox1.Value;
end;

Ray

[Ray Konopka]

Hi,
You can simply use the Value property of the combo box. If an item in the combo box is selected then the Value property returns the corresponding value for that item. If no item is selected, then Value returns an empty string.

Ray

[Ray Konopka]

Hi Marcos,

I apologize for the delay in responding. The short answer to your question is that you cannot filter CodeSite messages at the Dispatcher based on message type. You can filter messages based on Category at the Dispatcher level, but that is typically used once in a while in situations where filtering is needed but it is not possible to filter the messages at the program level.

Instead, most developers will filter the messages that get “sent” by CodeSite by creating multiple CodeSite loggers for use their applications. For example, one might create a csCritical logger (with its Category property set to Critical) that is always Enabled. That way, any CodeSite message sent by csCrtical will get dispatched to the destination. Other loggers might be named csDebug, csDevelop, csExternal, csCommunication, etc.

With the various loggers in place, developers simply use the appropriate logger to capture information. Moreover, many CodeSite users will provide a mechanism to enable/disable the various loggers used in their apps. This could be done through INI file settings, Registry entries, XML config files, etc.

Therefore, to control the amount of information generated by an app is handled by configuring the app and not by restricting the messages that are dispatched by the Dispatcher. Also, by using Categories, you can focus on the content of your CodeSite messages and not an arbitrary logging level for the message.

And finally, in order to update the Dispatcher settings, you need to have Admin rights. You can either start the Dispatcher as an Admin, or you can run the CodeSite Controller as an Admin at you will then be able to change the Dispatcher settings.

Ray

[Ray Konopka]

Hi Marc,
CodeSite does not currently support iOS, Android, Mac, or Linux targets, but supporting these platforms is definitely on the roadmap. As for FreePascal support, we’ll add it to our list of things to investigate.

Ray

[Ray Konopka]

Hi Randall,

The TRzSendMessage component uses the Simple Messaging API (MAPI). As a result, Microsoft does have some information on MAPI. One interesting issue that was recently reported regarding TRzSendMessage was an application built with Delphi 2007 but was running on a 64-bit OS with a 32-bit version of Outlook. There is an interesting page from Microsoft that talks about the bitness of MAPI applications and the operating systems they are running on. The link is:

https://docs.microsoft.com/en-us/office/client-developer/outlook/mapi/building-mapi-applications-on-32-bit-and-64-bit-platforms

Perhaps this is what you are running into.

Back to Simple MAPI. It really is a pretty simple interface and does rely on having an email client installed on the system. The component was originally created to facilitate applying for the Windows 95 Logo for an app. There are two big issues with Simple MAPI: 1) not all email clients support it the same way, and 2) when things go wrong, the errors returned from MAPI are notoriously vague–the most infamous being ErrorCode 2 – General Error.

As an alternative, you may wish to consider sending emails from you app using the TIdSMTP component. An email client is not necessary for this component to send emails. However, you do need to specify an SMTP server to actually send the email messages.

Ray

[Ray Konopka]

Hi Steve,

Glad you got it worked out.

Ray

[Ray Konopka]

CodeSite messages generated from both your EXE and your DLL will go to the CodeSite Dispatcher, which will allow messages from both sources to go to the same log file. The key is to get the Destination setup for both.

Is your DLL using the global CodeSite object or a separate TCodeSiteLogger instance? If it is using the global instance then it should use the same destination that was setup in the EXE. If it is a separate logger instance, the DLL logger will use either the Destination defined for the logger instance or the one defined for the CodeSiteManager. Therefore, I would suggest defining your desired log file destination and set it to the CodeSiteManager.DefaultDestination property. That way, all your loggers will use the same destination.

Ray

[Author]

Posts