FPiette

Are you writing both ends of the document exchange system? If you must access an existing system, then you must get the specification of the attachment.

This file is normally in Midware base directory. Attached to this message. OverbyteSObjThrd.pas

Please avoid asking any question not directly related to ICS in this ICS dedicated forum. Indy has his own support channels.

I had an application (A UI in front of an image SQLite database) using Direct2D 1.0 thru Delphi provided TDirect2DCanvas (VCL). This work well and it is fast. To be able to use recent features of Direct2D, I wrote a modified version of TDirect2DCanvas to support Direct2D 1.1 and later. For the changes, I followed this guide. It works nicely except it is ten times slower now! Measuring performance was easy: Simple with Direct2D 1.0 it is almost instantly (less than one second for 49 images as shown in the screen dump below while Direct2D 1.1 take roughly ten seconds. The code for rendering the bitmap is the same for both Direct2D 1.0 and 1.0 and is the following: BeginPaint(Handle, PaintStruct); RenderTarget.BeginDraw; RenderTarget.Clear(D2D1ColorF(FBackColor)); if FBitmapToPaint <> nil then begin RenderTarget.SetTransform(FTransform); RenderTarget.DrawBitmap(FBitmapToPaint, nil, 1.0, D2D1_BITMAP_INTERPOLATION_MODE_LINEAR, nil); end; RenderTarget.EndDraw; // Next line only for Direct2D 1.1 version DXGISwapChain.Present1(SyncInterval, PresentFlags, PresentParams); EndPaint(Handle, PaintStruct); RenderTarget is a ID2D1RenderTarget for Direct2D 1.0 and an ID2D1DeviceContext for Direct2D 1.1. FBitmapToPaint is a ID2D1Bitmap. PresentFlags and SyncInterval are always zero. PresentParams is a zeroed TDXGIPresentParameters structure. The code to initialize all the interfaces are inspired by the code shown on the guide I mentioned above. In the application, there are as much such small windows as fit on the application window (49 in the screen dump). The application currently does only image rendering: Loading JPG small files, scaling and rotating to fit the small window used for rendering. Those are thumbnails, so there are maybe 50 or 100 such small window on screen. No geometry, no text, no other drawing. Only a single bitmaps per window. I have not yet used anything specific to Direct2D 1.1. If can switch from one version to the other just by using Delphi provide Vcl.Direct2D unit in the uses clause, or using my own modified version for Direct2D V1.1 and later. My question are: 1) Is Direct2D 1.1 really slower than 1.0? (I suppose not) 2) Which tool (free if possible) can I use to measure everything involved in the creation of the window and the rendering so that I can find out what is slower exactly, hoping to find why it is slower. BTW: I am using Windows 10 1909.

Thanks, I'll have a look at it.

Then your request can't be satisfied because you don't provide any detail. There is no API that I am aware of the is generic across the kind of tool you ask. Please read again @Remy Lebeauanswer because it contain interesting hints.

Do you already have an idea how to do it? Or are you asking that we code it for you?

You should open a new message thread for that independent question.

In a multi-user environment, to increment CoyId, a transaction should be used along with SELECT FOR UPDATE statement and an UPDATE statement. Other database engine may use other syntax.

Depending on the rest of the application, I would go for SQLite or a full blown MS-SQL Server database.

If you have a table with your numbered company code, it is easy to find the max number has been allocated for a given company code. Isn't it? What kind of storage do you use? SQL database or other?

Do you have a chance to test the same program on another computer which has the same Delphi version?

Do you have the problem since the beginning or it once worked correctly? If it has worked in the past, somehow your debugger is corrupted. If you have no backup, reinstall Delphi.

Try with a much more simple program, a king of "Hello World" to narrow down the issue. A simple VCL form, with a single button with a click handle calling ShowMessage "Hello World". Compile for debug. Put a break point on the "begin" at the start of OnClick handler. When it, hit "trace into". And tell us what happens.

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.