I'm trying to build DataSnap server in C++ Builder XE as Windows Form Application. I use TIdSchedulerOfThreadPool as described here http://blog.marcocantu.com/blog/datasnap_deployment_performance.html. Under have load I get lots of EIdConnClosedGracefully exceptions which is probably normal, but the problem is that I get this exceptions as MessageBoxes from threads. I look for some events where i can suppress this messageboxes.
Are you seeing the messageboxes appear only while running your app inside of the debugger, or do you see them while running the app outside of the IDE as well? Inside the debugger is normal behavior, since they are exceptions afterall. The debugger shows popup messages for raised exceptions unless you tell it to ignore them. But outside of the IDE, the only way you can be seeing messagebox from worker threads is if either your own code is catching the exceptions and displaying the messageboxes yourself, or else DataSnap is showing them internally. EIdConnClosedGracefully is an Indy exception, and DataSnap does use Indy internally, but it is very unlikely that DataSnap would be displaying its own messageboxes. Indy certainly does not ever display a messagebox.
I'm seeing messageboxes outside of the IDE too. It comes from TWebRequestHandler (DataSnap). Here are stacktrace of thread that displays that messagebox:
:7c90e514 ntdll.KiFastSystemCallRet
:7e369418 user32.WaitMessage + 0xc
:7e3749c4 ; C:\WINDOWS\system32\user32.dll
:7e38a956 ; C:\WINDOWS\system32\user32.dll
:7e38a2bc ; C:\WINDOWS\system32\user32.dll
:7e3b63fd user32.MessageBoxTimeoutW + 0x7a
:7e3a0853 user32.MessageBoxExW + 0x1b
:7e3b6579 user32.MessageBoxW + 0x45
:004D6BBD Sysutils::ShowException(ExceptObject=????, ExceptAddr=????)
:0082b248 ; Webreq::TWebRequestHandler::HandleException
:0082b06f ; Webreq::TWebRequestHandler::HandleRequest
:0043dbdf ; Idhttpwebbrokerbridge::_16464
:0043dd23 Idhttpwebbrokerbridge::TIdHTTPWebBrokerBridge::DoCommandGet + 0x23
:0068AB4D Idcustomhttpserver::TIdCustomHTTPServer::DoExecute(Self=:00E9B9D0, AContext=:00F13660)
:0063F09A Idcontext::TIdContext::Run(Self=????)
:0049F9CD Classes::ThreadProc(Thread=:00ECA260)
:004EF72E System::ThreadWrapper(Parameter=:00F1EF10)
:7c80b729 ; C:\WINDOWS\system32\kernel32.dll
Related
At the moment I have a Delphi form running and upon losing connection to its Database/loss of network, it re-establishes and carries on.
The service is on a timer and each minute, it pops up with message box saying failure to connected to db on network [ip address]. This is at the start of the timer, a stored proc is ran.
I have all errors writing to a log file on the service local machine, is there a way I can suppress the message box appearing as I don't need it to appear all the time? by message box it is a windows exception box not a showMessageBox(). It automatically pops up when the exception hits but it will continuously hit whilst the machine boots up and re-establishes connection to the network.
The code I have is as follows
(*Call db Procedure*)
try
db.SQL.Clear;
db.SQL.Add('call dbProc();');
db.ExecSQL;
except
On E : Exception Do
begin
If E.ClassName = 'EIBInterBaseError' Then
begin
WriteToLog('Network Error : An error has occured whilst trying to communicate with the db outside the'
+ ' loop to catch up , please see user guide V.1.0.2.145',2);
reconnectdb;
end
else if E.ClassName = 'EADOError' then
begin
WriteToLog('Network Error : An error has occured whilst trying to communicate with the db outside the'
+ ' loop to catch up , please see user guide V.1.0.2.145',2);
reconnectDB;
end;
end;
end;
Based on your description (since you did not show any code), it sounds like each iteration of your loop is raising an exception that you are not catching, so it ends up in a default exception handler within the RTL that is then displaying the popup MessageBox. If this is the case, you need to catch the original exception using a try..except block around your code that is failing.
I've createdan application which communicates with external device using TCP/IP as a client. I'm using Synapse library (v40) for communication. Sometimes however communication freezes. I managed to get callstack with JclDebug,showing that despite defined timeout, receiving packets is the problem.
Delphi 2009 is used.
Is there anything I can do to fix this issue? Bug in Synapse?
[77297094] KiFastSystemCallRet
[006193FE] blcksock.TBlockSocket.InternalCanRead (Line 2741, "synapse\blcksock.pas")
[0061945C] blcksock.TBlockSocket.CanRead (Line 2764, "synapse\blcksock.pas")
[006185E5] blcksock.TBlockSocket.RecvPacket (Line 2324, "synapse\blcksock.pas")
[0061888F] blcksock.TBlockSocket.RecvTerminated (Line 2410, "synapse\blcksock.pas")
... my own code..
Edit: The blocking line is:
x := synsock.Select(FSocket + 1, #FDSet, nil, nil, TimeVal);
Select -function is from winsock2 API.
Edit2: TimeVal is set by Synapse code:
var
TimeVal: PTimeVal;
TimeV: TTimeVal;
..
TimeV.tv_usec := (Timeout mod 1000) * 1000;
TimeV.tv_sec := Timeout div 1000;
TimeVal := #TimeV;
if Timeout = -1 then
TimeVal := nil;
Original source code is here: http://synalist.svn.sourceforge.net/viewvc/synalist/trunk/blcksock.pas?revision=154&view=markup
Timeout used is 1000.
Edit3: I've two client threads running to communicate with two different hosts. It looks like only other one is hanging. Application has been running now since thursday. Thread #2 hung after 5 hours, but thread #1 is still running.
As I couldn't find the reason for the freeze, I changed by code a bit and now end up calling RecvTerminated with CRLF as terminater instead of '>', and it seems to work without stopping.
I have been having exceptions crop in my application, either stack overflow or our of memory. They show up in different places, depending on when the system has had enough. To put it another way, running the app twice won’t lead to the same exception in the same place.
I have some timers which cause database access. The AnyDac d/b component guys tell me that I can't reuse a global TADConnection but have to allocate it dynamically in each timer handler, which I have done.
I just thought that I had had a d'oh! moment when I looked at the latest stack trace.
fMainForm.TMainForm.GetToolNumberFromContext($31846FB4)
fMainForm.TMainForm.Received_HEART_BEAT($249AEFD0)
IdCommandHandlers.TIdCommand.DoCommand
IdCommandHandlers.TIdCommandHandler.DoCommand(???,$31846FB4,'')
IdCommandHandlers.TIdCommandHandler.Check('HEART_BEAT',$31846FB4)
IdCommandHandlers.TIdCommandHandlers.HandleCommand($31846FB4,'HEART_BEAT') <===
uADDatSManager.TADDatSRow.SetBlobLength($7DA10FDC,0,$C18DDDC,10,0,1,False)
uADDatSManager.TADDatSRow.SetBlobData($7DA10FDC,0,$C18DDDC,10,False)
uADDatSManager.TADDatSRow.SetData(0,$C18DDDC,10)
uADPhysMySQL.TADPhysMySQLCommand.FetchRow($7D2F4F90,nil)
uADPhysMySQL.TADPhysMySQLCommand.InternalFetchRowSet($7D2F4F90,nil,50)
uADPhysManager.DoFetch(0,50,50,False)
uADPhysManager.TADPhysCommand.FetchBase($7D2F4F90,False)
uADPhysManager.TADPhysCommandAsyncFetch.Execute
uADStanAsync.TADStanAsyncExecutor.ExecuteOperation(False)
uADStanAsync.TADStanAsyncExecutor.Run
uADPhysManager.TADPhysCommand.ExecuteTask(TADPhysCommandAsyncFetch($7DA24FEC) as IADStanAsyncOperation,TADPhysCommandAsyncFetch($7DA24FF8) as IADStanAsyncHandler,True)
uADPhysManager.TADPhysCommand.Fetch($7D2F4F90,False,True)
uADCompClient.TADCustomCommand.Fetch($7D2F4F90,False,True)
uADCompClient.TADCustomTableAdapter.Fetch(False)
uADCompClient.TADAdaptedDataSet.DoFetch($7D2F4F90,False,fdDown)
uADCompDataSet.TADDataSet.InternalFetchRows(False,True,fdDown)
uADCompDataSet.TADDataSet.GetRecord($7DA1AFF4,gmNext,True)
Data.DB.TDataSet.GetNextRecord
Data.DB.TDataSet.GetNextRecords
Data.DB.TDataSet.SetBufferCount(???)
Data.DB.TDataSet.UpdateBufferCount
Data.DB.TDataSet.DoInternalOpen
Data.DB.TDataSet.OpenCursor(???)
uADCompDataSet.TADDataSet.OpenCursor(False)
uADCompClient.TADRdbmsDataSet.OpenCursor(False)
Data.DB.TDataSet.SetActive(???)
uADCompDataSet.TADDataSet.SetActive(True)
Data.DB.TDataSet.Open
uADCompClient.TADRdbmsDataSet.Open('SELECT * FROM tagged_chemicals',(...),(...))
uADCompClient.TADRdbmsDataSet.Open('SELECT * FROM tagged_chemicals')
fMainForm.TMainForm.CheckEndOfScheduleTimerTimer($B116FAC)
Vcl.ExtCtrls.TTimer.Timer
Vcl.ExtCtrls.TTimer.WndProc(???)
System.Classes.StdWndProc(133584,275,1,0)
:768a62fa ; C:\Windows\syswow64\USER32.dll
:768a6d3a USER32.GetThreadDesktop + 0xd7
:768a77c4 ; C:\Windows\syswow64\USER32.dll
:768a788a USER32.DispatchMessageW + 0xf
Vcl.Forms.TApplication.ProcessMessage(???)
I don't understand that marked line, the sudden switch from AnyDac to Indy code
IdCommandHandlers.TIdCommandHandlers.HandleCommand($31846FB4,'HEART_BEAT') <===
uADDatSManager.TADDatSRow.SetBlobLength($7DA10FDC,0,$C18DDDC,10,0,1,False)
Can someone please explain it? Thanks
My first thought was that Indy was interrupting AnyDac, perhaps because it called Applciation.ProcessMessages or similar, but I don't see that on the stack ...
But if it can do that, then can it interrupt "normal" non-timer handler code?
I was sure that I had it cracked and that the problem was that my TCP command handlers were reusing an AnyDac component used by something else ... then I looked at my code and saw that there is no database access in the command handlers or in anything that they call.
I am stumped. Does what I wrote even make sense? Can anyone offer any advice?
Thanks a 1,000,000 in advance for any help.
Indy's commands handlers are used by TIdCmdTCPServer and TIdCmdTCPClient, which are both multi-threaded components. The command handlers are invoked inside of worker threads that Indy creates internally. There is no way that a command handler can interrupt an operation that is running in a different thread.
I am a long time Delphi dev and in the past I use a third party tool for logging and debugging while developing (called Smart Inspect) however now that I've upgraded to Delphi XE I want to try and use the IDE for debugging.
My question is, given a function like
procedure MyFunction;
var
str : string;
begin
str := 'Foo';
//Debug, show value of str?
str := AnotherFunction(str);
//Debug, show value of str?
end;
how can I debug and get the value of str, without doing stupid things like
showmessage(str);
if there is a video somewhere (or article) then I am more than happy to read.
Is there a way to watch/output the value of variables.
If you want to use the IDE Debugger only, then do the following:
put a breakpoint somewhere
right click on the breakpointr circle and choose "Breakpoint Properties ..."
press "Advanced" button to show more options
uncheck "Break" checkbox
then use "Log message" and "Eval expression" edit boxes to enter trace values
Such messages will be send to "Event Log" debugger pane. Right click on the pane and choose "Properties". There you can filter ("Messages") / hilight ("Colors") the trace messages as you whish.
Well, Delphi XE comes with CodeSite logging, but I get the feeling you're talking about the debugger itself.
If you place a breakpoint in a routine, it will break to the debugger when it hits it. From there, you've got a Local Variables pane and a Watches pane along the left side of the IDE. Local Variables will show the value of all locals, and Watches lets you set up expressions whose value it will keep track of.
You can also get something similar to a watch, but with more detailed information (especially for structured types such as objects) by using Inspect (Alt-F5). Also, the Evaluate/Modify (Ctrl-F7) will allow you to type in expressions and evaluate them. It's not quite as detailed as Inspect, but it gives you a lot more flexibility.
If you familiarize yourself with these tools, you'll find debugging much easier.
1) You can use OutputDebugString Function to output string to debug window
2) You can use CodeSite Express. I recommend video from CodeRage 5 as a starting point for using CodeSite
Other answers are all correct.
My personal favorite technique (same as the answer by da-soft) is to create a breakpoint, that logs a message to the event log, containing a value that I want logged, and does not actually "break" (that is, execution continues without you hitting the Run icon). Then every time that line of code is reached, I get my message, and my values in the log. Since I can go back and read the history, as well as see the current values, I find this more useful than merely using the debugger watch window.
But since Delphi XE includes CodeSite, you can go far beyond what expression evaluation in breakpoints does for you. Code Site however requires that you modify your code to add some logging. But it's much better than a message box.
You can also use OutputDebugString(PChar(s)) to output any string to the debugger. Since this can contain whatever you want, it's a very nice way to debug but not show stuff to the end user.
In many of my applications, I have a special trace buffer, which is circular (that is, it keeps only the last 500 or so lines). When ever I see a problem, not only do I get a stack traceback, I also save that in-memory trace log, so I have some history on what was going on just before my problem.
You can also check out the Log 4 Delphi project.
I prefer debugger hints. After breaking to the debugger move your mouse to the "str" anywhere in your code and you will see its current value. Also you can highlight some statement by a mouse and evaluate it. For example highlight "AnotherFunction(str)" and place your mouse over it.
Nothing wrong with any of the other answers but I just wanted to add these useful functions.
procedure DebugString ( const s : string ) ; overload ;
begin
{$IFDEF DEBUG}
OutputDebugString ( PChar ( s ) ) ;
{$ENDIF}
end ;
procedure DebugString ( const s : string ; args : array of const ) ; overload ;
begin
{$IFDEF DEBUG}
OutputDebugString ( PChar ( Format ( s , args ) ) ) ;
{$ENDIF}
end ;
As far as I've been able to find out, Windows doesn't offer an API function to tell what application has registered a global hotkey (via RegisterHotkey). I can only find out that a hotkey is registered if RegisterHotkey returns false, but not who "owns" the hotkey.
In the absence of a direct API, could there be a roundabout way? Windows maintains the handle associated with each registred hotkey - it's a little maddening that there should be no way of getting at this information.
Example of something that likely wouldn't work: send (simulate) a registered hotkey, then intercept the hotkey message Windows will send to the process that registered it. First, I don't think intercepting the message would reveal the destination window handle. Second, even if it were possible, it would be a bad thing to do, since sending hotkeys would trigger all sorts of potentially unwanted activity from various programs.
It's nothing critical, but I've seen frequent requests for such functionality, and have myself been a victim of applications that register hotkeys without even disclosing it anywhere in the UI or docs.
(Working in Delphi, and no more than an apprentice at WinAPI, please be kind.)
One possible way is to use the Visual Studio tool Spy++.
Give this a try:
Run the tool (for me, it's at C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\Tools\spyxx_amd64.exe or you can download it). Note: there is spyxx.exe (32-bit version) and spyxx_amd64.exe (64-bit version) - if you don't see anything in 64-bit use the 32-bit version (ie.catches messages only in same architecture)
In the menu bar, select Spy -> Log messages... (or hit Ctrl + M)
Check All Windows in System in the Additional Windows frame
Switch to the Messages tab
Click the Clear All button
Select WM_HOTKEY in the listbox, or check Keyboard in Message Groups (if you're OK with more potential noise)
Click the OK button
Press the hotkey in question (Win + R, for example)
Select the WM_HOTKEY line in the Messages (All Windows) window, right click, and select Properties... in the context menu
In the Message Properties dialog, click the Window Handle link (this will be the handle for the window that received the message)
Click the Synchronize button on the Window Properties dialog. This will show the window in the main Spy++ window treeview (if it's windows itself or some popup application it shows nothing).
On the Window Properties dialog, select the Process tab
Click the Process ID link. This will show you the process (In my Win + R case: EXPLORER)
Your question piqued my interest, so I've done a bit of digging and while, unfortunately I don't have a proper answer for you, I thought I'd share what I have.
I found this example of creating keyboard hook (in Delphi) written in 1998, but is compilable in Delphi 2007 with a couple of tweaks.
It's a DLL with a call to SetWindowsHookEx that passes through a callback function, which can then intercept key strokes: In this case, it's tinkering with them for fun, changing left cursor to right, etc. A simple app then calls the DLL and reports back its results based on a TTimer event. If you're interested I can post the Delphi 2007 based code.
It's well documented and commented and you potentially could use it as a basis of working out where a key press is going. If you could get the handle of the application that sent the key strokes, you could track it back that way. With that handle you'd be able to get the information you need quite easily.
Other apps have tried determining hotkeys by going through their Shortcuts since they can contain a Shortcut key, which is just another term for hotkey. However most applications don't tend to set this property so it might not return much. If you are interested in that route, Delphi has access to IShellLink COM interface which you could use to load a shortcut up from and get its hotkey:
uses ShlObj, ComObj, ShellAPI, ActiveX, CommCtrl;
procedure GetShellLinkHotKey;
var
LinkFile : WideString;
SL: IShellLink;
PF: IPersistFile;
HotKey : Word;
HotKeyMod: Byte;
HotKeyText : string;
begin
LinkFile := 'C:\Temp\Temp.lnk';
OleCheck(CoCreateInstance(CLSID_ShellLink, nil, CLSCTX_INPROC_SERVER, IShellLink, SL));
// The IShellLink implementer must also support the IPersistFile
// interface. Get an interface pointer to it.
PF := SL as IPersistFile;
// Load file into IPersistFile object
OleCheck(PF.Load(PWideChar(LinkFile), STGM_READ));
// Resolve the link by calling the Resolve interface function.
OleCheck(SL.Resolve(0, SLR_ANY_MATCH or SLR_NO_UI));
// Get hotkey info
OleCheck(SL.GetHotKey(HotKey));
// Extract the HotKey and Modifier properties.
HotKeyText := '';
HotKeyMod := Hi(HotKey);
if (HotKeyMod and HOTKEYF_ALT) = HOTKEYF_ALT then
HotKeyText := 'ALT+';
if (HotKeyMod and HOTKEYF_CONTROL) = HOTKEYF_CONTROL then
HotKeyText := HotKeyText + 'CTRL+';
if (HotKeyMod and HOTKEYF_SHIFT) = HOTKEYF_SHIFT then
HotKeyText := HotKeyText + 'SHIFT+';
if (HotKeyMod and HOTKEYF_EXT) = HOTKEYF_EXT then
HotKeyText := HotKeyText + 'Extended+';
HotKeyText := HotKeyText + Char(Lo(HotKey));
if (HotKeyText = '') or (HotKeyText = #0) then
HotKeyText := 'None';
ShowMessage('Shortcut Key - ' + HotKeyText);
end;
If you've got access to Safari Books Online, there is a good section about working with shortcuts / shell links in the Borland Delphi 6 Developer's Guide by Steve Teixeira and Xavier Pacheco. My example above is a butchered version from there and this site.
Hope that helps!
After some research, it appears that you'd need to get access to the internal structure that MS uses to store the hotkeys. ReactOS has a clean room implementation that implements the GetHotKey call by iterating an internal list and extracting the hotkey that matches the parameters to the call.
Depending on how close ReactOS' implementation is to the MS implementation, you may be able to poke around in memory to find the structure, but that's over my head...
BOOL FASTCALL
GetHotKey (UINT fsModifiers,
UINT vk,
struct _ETHREAD **Thread,
HWND *hWnd,
int *id)
{
PHOT_KEY_ITEM HotKeyItem;
LIST_FOR_EACH(HotKeyItem, &gHotkeyList, HOT_KEY_ITEM, ListEntry)
{
if (HotKeyItem->fsModifiers == fsModifiers &&
HotKeyItem->vk == vk)
{
if (Thread != NULL)
*Thread = HotKeyItem->Thread;
if (hWnd != NULL)
*hWnd = HotKeyItem->hWnd;
if (id != NULL)
*id = HotKeyItem->id;
return TRUE;
}
}
return FALSE;
}
I presume this thread on sysinternals was asked by someone related to this question, but I thought I'd link to it anyway to keep the two together. The thread looks very intriguing, but I suspect that some deep dive spelunking would need to happen to figure this out without access to the MS internals.
Off the top of my head, you might try enumerating all windows with EnumWindows, then in the callback, send WM_GETHOTKEY to each window.
Edit: Apparrently I was wrong about that. MSDN has more information:
WM_HOTKEY is unrelated to the WM_GETHOTKEY and WM_SETHOTKEY hot keys. The WM_HOTKEY message is sent for generic hot keys while the WM_SETHOTKEY and WM_GETHOTKEY messages relate to window activation hot keys.
Note: Here is a program purporting to have the functionality you are looking for. You could try decompiling it.
Another thread mentions a global NT level keyboard hook:
Re-assign/override hotkey (Win + L) to lock windows
maybe you can get the handle of the process that called the hook that way, which you can then resolve to the process name
(disclaimer: I had it in my bookmarks, haven't really tried/tested)
I know you can intercept the stream of messages in any window within your own process - what we used to call subclassing in VB6. (Though I do not remember the function, perhaps SetWindowLong?) I am unsure if you can do this for windows outside your own process. But for the sake of this post lets assume you find a way to do that. Then you can simply intercept the messages for all top level windows, monitor for the WM_HOTKEY message. You wouldn't be able to know all the keys right off the bat, but as they were pressed you could easily figure out what application was using them. If you persisted your results to disk and reloaded each time your monitor application was run you could increase the performance of your application over time.
This doesn't exactly answer the part of the question that is about the Windows API, but it answers the part of the question that is about a list of global hotkeys and the applications that "own" them.
The free Hotkey Explorer at http://hkcmdr.anymania.com/ shows a list of all global hotkeys and the applications that own them. This just has helped me figure out why an application-specific shortcut key stopped working and how to fix it (by reconfiguring the registered global hotkey in the app that had it registered), within a few seconds.