FPiette

Try creating a component with the bare minimum to reproduce your problem and a strict minimal application using it and demonstrating the issue. Then publish your code here.

Does this issue happens with a simple "hello World" program? Or is it observed only for one of your programs?

You need to run the program under Delphi debugger and for that you need the source code and a Delphi license. You'd better ask the developer...

You don't help yourself... Shell is a function you wrote. We cannot tell you what errors it returns. Modify your code to get the error code or error message INSIDE the Shell function, everywhere an API function is called.

You said the error occur in Shell function and then you showed code for Shell function... So where EXACTLY is the error produced and which error is this EXACTLY. We cannot help you if you to help us...

What is the exact error you get? Do you get the error at compile time or at runtime? What is the function Shell? I guess it is similar to ShellExecute?

I would suggest to run the applications under the debugger. One possibility is that WIN10 has different layout/structure than XP and a bug crashing some data structure can have zero adverse effect on XP while it crashes WIN10. Since this happens after "some time", it is possible that some resource is exhausted and then cause the above mentioned unknown bug.

TWSocket has ThreadDetach and ThreadAttach methods to switch from one thread (The one which created the component or the last attached thread) to another. This simply destroy the window handle (ThreadDetach) and recreate it (ThreadAttach). There should be some hook or event in IntraWeb to plug the calls to those methods.

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?