FPiette

ICS doesn't patch anything at all. It makes use of Windows API directly on his own. ICS register his own window class and create all his hidden windows using that class. This doesn't interfere with anything and it is perfectly respectful of Microsoft documentation. That test application is just a test to understand if IntraWeb has a message pump. Nothing more.

ICS has his own AllocateHWnd method that is thread safe. It make use of a critical section to protect the class registration (GetClassInfo and RegisterClass) and then use CreateWindowEx to create the handle. For those interested, look at TIcsWndHandler.AllocateHWnd in unit OverbyteIcsWndControl. This thread is full of false assertions about ICS and Windows. They say messages doesn't work in thread and that is completely wrong. Microsoft documentation says : ICS is designed to work within threads. ICS make use of Windows messages which is perfectly correct to use within threads if you follow the rules (See above: Have a message pump in the thread which is not the default. A thread is like a console mode application: it has no message pump by default). ICS comes with a number of multi thread samples. In the IntraWeb forum, they just want to hide a problem they overlooked with IntraWeb and they want you to use their product. In my first reply (March 7) I told you : IntraWeb has no message pump in their threads so as I said, put all your stuff within a single thread that you create and having his own message pump (See the samples provided with ICS).

Look at TMessageManager class (System.Messaging unit). They implemented a class var for the default manager and a class property with a getter that initialize the call var if not already done, then return the instance.

I'm converting some software of mine to cross platform (Mainly Windows and Linux). I have to replace Windows WaitForMultipleObjects where objects to be waited may be any combination of several pipe handles (ready to read), socket handles, mutex and semaphores. I don't see anything obvious in unit System.SyncObjs. Any help appreciated.

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 ?