FPiette

Yes, now I can reproduce. This is a bug IMO. You should write a bug report at https://quality.embarcadero.com By the way, what you name "EditBox" is a "ComboBox" or a "drop down list box".

I followed your steps and... I cannot reproduce the behavior. Maybe you have some "extension", "wizard" or whatever added to the IDE that produce that. By the way, I'm no sure what is "the object inspector edit box" where to " type in any component that has the letter 'e' anywhere in it ". There is an editbox to search for a property and many properties have an editbox to enter their value. Maybe you confuse with component toolbar? That's why I asked a screen dump to be sure about what you talk about.

Using Microsoft Spy++, it is easy to see if the window created by AllocateHWnd() was silently destroyed. I tested this with the VCL application and Spy++ correctly show the invalid window handle. Display the window properties dialog and refresh that dialog periodically, then when the window handle is destroyed, Spy++ will display "Invalid Window". I cannot try with IntraWeb because I don't have that product. Note that when the window is destroyed, the corresponding WndProc is called with WM_DESTROY (2) and WM_NCDESTROY (130) messages before the window is really destroyed and this is shown by the WndProc in the VCL test code I wrote and should be shown by the corresponding IntraWeb code. Maybe IntraWeb intercept AllocateHWnd/PostMessage/WndProc and subclass the created window and then somehow break the usual win32 API behavior.

I don't see that behavior. Could you post a screen dump showing the object inspector and where the caret is?

You're welcome. Whenever you get the solution, please post it here.

Now I'm convinced that this is an issue with IntraWeb. The test program has nothing to do with ICS. It only make use of the same fundamental Windows functions that ICS uses. If the test program doesn't work, then ICS won't work either. I suggest you contact IntraWeb support with the test programs (Both VCL and IntraWeb) so that they can fix their code.

So the handle is correct and yet the error 1400 (Invalid handle) is triggered. Maybe PostMessage is not the one we think it is. Try with a fully qualified name: procedure TForm1.PostMessageButtonClick(Sender: TObject); begin if FWinHandle = INVALID_HANDLE_VALUE then Memo1.Lines.Add('Window handle not created') else if not WinApi.Windows.PostMessage(FWinHandle, WM_USER, 1234, 5678) then Memo1.Lines.Add(Format('PostMessage failed with error %d (HWND=%d)', [GetLastError, FWinHandle])); end;

Windows Error code 1400 is ERROR_INVALID_WINDOW_HANDLE this means PostMessage has not received the handle created. Make sure the is no typo in the code you copied from my example and once more change the line to : Memo1.Lines.Add(Format('PostMessage failed with error %d (HWND=%d)', [GetLastError, FWinHandle])); The handle value should be the same as the one displayed after call to AllocateHWnd. One possible mistake you have done is not passing FWinHandle to PostMessage.

Probably no message pump. Let's add the error number to know more. Replace Memo1.Lines.Add('PostMessage failed'); by Memo1.Lines.Add(Format('PostMessage failed with error %d', [GetLastError])); then try again and tell us the error code PostMessage returns.

As Chris Rutkow said above, you code: with sktClient do begin Proto := 'tcp'; Port := 'localhost'; Addr := 'telnet'; LineMode := True; LineEnd := #13#10; Connect; end Should become: with sktClient do begin Proto := 'tcp'; Port := 'telnet'; Addr := '127.0.0.1'; // Using dotted IP is faster LineMode := True; LineEnd := #13#10; Connect; end;

It works again for me this morning.

Does not work for me. I get the login page but my credentials are invalid.

I have the need to use custom messages in a FMUX (Firemonkey Linux) application. Something similar to Windows PostMessage / SendMessage / AllocateHWnd / DeallocateHWnd / WndProc / Message handlers and all that stuff. Any idea?

I've found how to do it, more or less. This invokes TMessageManager class. There is only a SendMessage, no PostMessage. And there is no thread switch like in Windows messaging system. When you call SendMessage from a thread, the message subscriber (That is the message handler in Windows speaking) is directly called, that is it runs in the context of the sending thread. Actually there is neither a message queue which is logical since there is no PostMessage to queue a message. I can probably build the missing parts above the existing...

Yes and no... The OS already has a queue somewhere and FMUX is using it. The real problem is installing the custom message handler and posting message in that queue. FMUX already has HandleMessage and ProcessMessage but I have not found anything to post my own message and install a handler for it.

Here is a sample simple application: Delphi unit : unit WinHandleTestMain; interface uses Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics, Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls; type TForm1 = class(TForm) CreateHWNDButton: TButton; Memo1: TMemo; PostMessageButton: TButton; DestroyHWNDButton: TButton; procedure CreateHWNDButtonClick(Sender: TObject); procedure DestroyHWNDButtonClick(Sender: TObject); procedure PostMessageButtonClick(Sender: TObject); private FWinHandle : HWND; procedure WndProc(var Msg: TMessage); public constructor Create(AOwner : TComponent); override; end; var Form1: TForm1; implementation {$R *.dfm} constructor TForm1.Create(AOwner: TComponent); begin inherited; FWinHandle := INVALID_HANDLE_VALUE; end; procedure TForm1.CreateHWNDButtonClick(Sender: TObject); begin if FWinHandle <> INVALID_HANDLE_VALUE then begin System.Classes.DeallocateHWnd(FWinHandle); FWinHandle := INVALID_HANDLE_VALUE; Memo1.Lines.Add('Window handle destroyed') end; FWinHandle := System.Classes.AllocateHwnd(WndProc); if FWinHandle = INVALID_HANDLE_VALUE then Memo1.Lines.Add('Error creating window handle') else Memo1.Lines.Add(Format('Window handle create %d', [FWinHandle])); end; procedure TForm1.DestroyHWNDButtonClick(Sender: TObject); begin if FWinHandle = INVALID_HANDLE_VALUE then Memo1.Lines.Add('Window handle not created yet') else begin System.Classes.DeallocateHWnd(FWinHandle); FWinHandle := INVALID_HANDLE_VALUE; Memo1.Lines.Add('Window handle destroyed') end; end; procedure TForm1.PostMessageButtonClick(Sender: TObject); begin if FWinHandle = INVALID_HANDLE_VALUE then Memo1.Lines.Add('Window handle not created') else if not PostMessage(FWinHandle, WM_USER, 1234, 5678) then Memo1.Lines.Add('PostMessage failed'); end; procedure TForm1.WndProc(var Msg: TMessage); begin Memo1.Lines.Add(Format('MSG=%d', [Msg.Msg])); end; end. The VCL form: object Form1: TForm1 Left = 0 Top = 0 Caption = 'Form1' ClientHeight = 289 ClientWidth = 382 Color = clBtnFace Font.Charset = DEFAULT_CHARSET Font.Color = clWindowText Font.Height = -12 Font.Name = 'Segoe UI' Font.Style = [] PixelsPerInch = 96 TextHeight = 15 object CreateHWNDButton: TButton Left = 40 Top = 32 Width = 98 Height = 25 Caption = 'Create HWND' TabOrder = 0 OnClick = CreateHWNDButtonClick end object Memo1: TMemo Left = 40 Top = 72 Width = 297 Height = 185 Lines.Strings = ( 'Memo1') TabOrder = 1 end object PostMessageButton: TButton Left = 144 Top = 32 Width = 89 Height = 25 Caption = 'PostMessage' TabOrder = 2 OnClick = PostMessageButtonClick end object DestroyHWNDButton: TButton Left = 240 Top = 32 Width = 97 Height = 25 Caption = 'Destroy HWND' TabOrder = 3 OnClick = DestroyHWNDButtonClick end end

Could you connect to the server using Windows command line utility telnet? Use this command line: telnet 195.29.150.117 25 BTW: 25 is standard SMTP port. If connection fails, then as Angus said, it is probably a firewall issue. If it succeed, it should also succeed with ICS.

What EXACT error message do you receive "connection is rejected" is not enough to tell. Which protocol are you using with Outlook? Outlook support several protocols. You have to look in Outlook mail account configuration. Make sure the account is configured as SMTP (mail send) and POP3 (Mail receive), or SMTPS/POP3S if SSL/TLS are used.

Can you confirm if IntraWeb has a message pump? To check, use Classes.AllocateHWnd to create a hidden window handle and attache a WndProc to it. Then from a button in your user interface, PostMessage a message to that window handle and from the WndProc, check if the message is received. First check in a normal VCL application to be sure you understand how it works. Then check within an IntraWeb application.

Forget about D7! Try with recent Delphi version. Community Edition is free (Commercial use has some restrictions) and good.

Which IntraWeb version are you using ?

I have zero knowledge about IntraWeb but I call tell you the requirement for ICS : You need a message pump to have the events triggered. If IntraWeb lacks a message pump, you may pump all your ICS stuff within a single thread having his own message pump.

Not directly supported, but solutions exists. I don't recommend mixing VCL and FMX.

Should be: A := StrToInt ('$' + Result1);

This question is worth a specific publication. Please post it with a proper subject.