The up/down buttons on a TIWCGJQSpinEdit are very, very small on form creation! Pressing F5 or even F12 for developer tools puts them right, but it's annoying for the end user. Is there a simple fix so that they appear properly, right from the go?
I have some controls that dynamically cause tabs on a TIWCGJQTabs control to appear or disappear, depending on their value. Up until now, I've used AjaxRerender on the TIWCGJQTabs to reflect the change immediately. However, if there is a TIWCGJQGrid on the tab being revealed, it does not render properly (or at all, really) in the latest DevTools version. I have to do a full refresh of the whole form for it to appear. Any suggestions?
I'm using the TaurusTLS components in my app for both SMTP and making calls to Microsoft Graph. It's replaced earlier calls using the Indy SSL components. I've put the OpenSSL 4 DLLs in the application directory and it all works fine.. EXCEPT... it seems I still have to leave the old OpenSSL libraries as well! If I remove them, I get an error on startup that the SSL library couldn't be loaded. I'm using the latest Intraweb version - is there any setting in the server controller to manage this or does Intraweb still use those old libraries for listening?
Any image that I create and a TIWPaintBox seems to be clipped at 1000 pixels horizontally. I have checked that clipping is not enabled on the containing component. Can anyone tell me why this may be?
How does Intraweb and IWDevTools (to give it its new name!) decide whether to load the readable CSS version or the minimised version? I have two apps that behave differently (one loads cgcss and the other cgcss-min) so I guess I must have a setting somewhere - but I've no idea where it is! Can you tell me, please?
Hello. I’m unable to link a project that uses the TIWSummernote component because the required object files (IWCompSummernote.obj/IWCompSummernote.o) are missing from the installation folder.
I am trying to figure out a way to implement a kanban like control where I have columns of items that I can drag from one column to next. Is there a general way to accomplish this with any known IW components?
We recently migrated a Windows Service application from Indy+TaurusTLS to Http.sys (TIWStartHSys.Execute) in IntraWeb 16 / Delphi 13.
On every successful service start, TIWServiceWorker writes an informational line directly to <exe-name>.log (and to the Windows Event Log):
HTTP(S) server active using binding(s): http://+:80/,https://+:443/
We'd like to handle this ourselves — route it through our own logging infrastructure, decide the format, decide whether/where it gets written — rather than have TIWServiceWorker write it directly and unconditionally.
We looked into intercepting this from our own TIWServerControllerBase descendant, but as far as we can tell TIWServiceWorker is an internal service-bootstrap class unrelated to TIWServerControllerBase, and it runs before our own OnCreate/OnConfig handlers ever get control — so we don't have an obvious hook to intercept it from application code.
Is there a supported event, callback, or override point (on TIWServiceWorker or elsewhere) that lets application code take over this logging, or would this need to be a feature request?
Environment: IntraWeb 16, Delphi 13 (RAD Studio), Windows Server 2022, Http.sys server (IWStartHSys), 64-bit.
Delphi 12.2 IW 16.2.2 32bit ISAPI application
[*]ServerController.ComInitialization = ciNone
[*]IWRtlFix is the first unit in the DPR uses clause, before IWInitISAPI
[*]We are experiencing a recurring crash in a 32-bit IntraWeb ISAPI application hosted by IIS.
The most recent crash occurred on September 7, 2026, at 11:31:16 AM, in w3wp.exe PID 3652.
The outer exception is:
0xC000041D
Internal exception: 0xC0000005
Null-address access
Exception thread OS ID: 6256
The relevant stack sequence reported by DebugDiag is:
TADOConnection.Destroy
→ ADO connection-point Unadvise
→ DestroyAsyncEvents
→ msado15!_FireEventOnMainThread
→ user32!PeekMessageW
→ WM_SETTINGCHANGE
→ repeated IWRtlFix.StdWndProc callbacks
→ call to address 0x00000000
DebugDiag did not have Delphi symbols and displayed the repeated frame as:
SysInit.@_dbk_fcall_wrapper+3EE01E
Using the exact MAP file for the DLL loaded by the crashed process:
SysInit.@_dbk_fcall_wrapper is at $000127A8.
$000127A8 + $003EE01E = $004007C6.
IWRtlFix.StdWndProc begins at $004007B0.
Therefore, the repeated frame is:
IWRtlFix.StdWndProc + $16
This frame appears 338 consecutive times in the reported stack.
DebugDiag also displayed the Delphi caller below ADO as:
IWInitISAPI.TerminateExtension+1374CB
The exact MAP resolves it as follows:
IWInitISAPI.TerminateExtension is at $0041FBE4.
$0041FBE4 + $001374CB = $005570AF.
Data.Win.ADODB.TADOConnection.Destroy begins at $0055703C.
Therefore, this frame is:
Data.Win.ADODB.TADOConnection.Destroy + $73
The Windows message arguments captured in the stack are:
HWND = 0x0FB008A
Message = 0x001A (WM_SETTINGCHANGE)
wParam = 0
lParam = 0x0110D2F8
Memory at lParam contains the following UTF-16 bytes:
64 00 65 00 76 00 69 00 63 00 65 00 73 00 00 00
This decodes to:
devices
The exception context ends with EIP = 0x00000000, consistent with an indirect call to a null procedure address from the StdWndProc/object-instance callback path.
We have observed the same crash signature in multiple w3wp processes and application builds. Previous crashes also involved WM_SETTINGCHANGE with the text “devices”, ADO teardown and a long repeated StdWndProc callback chain.
Moving IWRtlFix before IWInitISAPI changed the addresses and the symbol labels, but did not prevent the crash.
Our current hypothesis is that a window-procedure/object-instance callback is stale, invalid, or recursively linked when ADO pumps Windows messages during TADOConnection destruction. We understand that the precise underlying lifecycle defect still needs confirmation.
Could you please advise:
Is this a known issue in IWRtlFix or IntraWeb 16.2.2?
Is there a newer IWRtlFix implementation or patch applicable to Delphi 10.2.3?
Could the patched StdWndProc/object-instance implementation retain an invalid callback during ADO message pumping?
Are there additional diagnostics we can add around IW_MakeObjectInstance/IW_FreeObjectInstance?
Is there a recommended way to prevent this interaction during TADOConnection destruction?
The attached DebugDiag CrashHangAnalysis report contains the complete reported stack and module information.
We can provide the full dump privately if it is strictly required, but we prefer to begin with the report and the symbol/memory evidence above.
Thank you.
(09-08-2026, 01:48 AM)alex.trejo@tttnet.com.mx Wrote: Delphi 12.2 IW 16.2.2 32bit ISAPI application
[*]ServerController.ComInitialization = ciNone
[*]IWRtlFix is the first unit in the DPR uses clause, before IWInitISAPI
[*]We are experiencing a recurring crash in a 32-bit IntraWeb ISAPI application hosted by IIS.
The most recent crash occurred on September 7, 2026, at 11:31:16 AM, in w3wp.exe PID 3652.
The outer exception is:
0xC000041D
Internal exception: 0xC0000005
Null-address access
Exception thread OS ID: 6256
The relevant stack sequence reported by DebugDiag is:
TADOConnection.Destroy
→ ADO connection-point Unadvise
→ DestroyAsyncEvents
→ msado15!_FireEventOnMainThread
→ user32!PeekMessageW
→ WM_SETTINGCHANGE
→ repeated IWRtlFix.StdWndProc callbacks
→ call to address 0x00000000
DebugDiag did not have Delphi symbols and displayed the repeated frame as:
SysInit.@_dbk_fcall_wrapper+3EE01E
Using the exact MAP file for the DLL loaded by the crashed process:
SysInit.@_dbk_fcall_wrapper is at $000127A8.
$000127A8 + $003EE01E = $004007C6.
IWRtlFix.StdWndProc begins at $004007B0.
Therefore, the repeated frame is:
IWRtlFix.StdWndProc + $16
This frame appears 338 consecutive times in the reported stack.
DebugDiag also displayed the Delphi caller below ADO as:
IWInitISAPI.TerminateExtension+1374CB
The exact MAP resolves it as follows:
IWInitISAPI.TerminateExtension is at $0041FBE4.
$0041FBE4 + $001374CB = $005570AF.
Data.Win.ADODB.TADOConnection.Destroy begins at $0055703C.
Therefore, this frame is:
Data.Win.ADODB.TADOConnection.Destroy + $73
The Windows message arguments captured in the stack are:
HWND = 0x0FB008A
Message = 0x001A (WM_SETTINGCHANGE)
wParam = 0
lParam = 0x0110D2F8
Memory at lParam contains the following UTF-16 bytes:
64 00 65 00 76 00 69 00 63 00 65 00 73 00 00 00
This decodes to:
devices
The exception context ends with EIP = 0x00000000, consistent with an indirect call to a null procedure address from the StdWndProc/object-instance callback path.
We have observed the same crash signature in multiple w3wp processes and application builds. Previous crashes also involved WM_SETTINGCHANGE with the text “devices”, ADO teardown and a long repeated StdWndProc callback chain.
Moving IWRtlFix before IWInitISAPI changed the addresses and the symbol labels, but did not prevent the crash.
Our current hypothesis is that a window-procedure/object-instance callback is stale, invalid, or recursively linked when ADO pumps Windows messages during TADOConnection destruction. We understand that the precise underlying lifecycle defect still needs confirmation.
Could you please advise:
Is this a known issue in IWRtlFix or IntraWeb 16.2.2?
Is there a newer IWRtlFix implementation or patch applicable to Delphi 10.2.3?
Could the patched StdWndProc/object-instance implementation retain an invalid callback during ADO message pumping?
Are there additional diagnostics we can add around IW_MakeObjectInstance/IW_FreeObjectInstance?
Is there a recommended way to prevent this interaction during TADOConnection destruction?
The attached DebugDiag CrashHangAnalysis report contains the complete reported stack and module information.
We can provide the full dump privately if it is strictly required, but we prefer to begin with the report and the symbol/memory evidence above.
Thank you.
