How to know what file was changed (it's name) on Change Event of TJvChangeNotify (JEDI) or TShellChangeNotifier?
Thanks!
Both components use FindFirstChangeNotification to monitor changes. As indicated in its documentation the function does not provide information on what triggered the notification. As such the only possible way to find out what happened using these components is to keep a snapshot of the monitored folder and perform a comparison after a change occurs.
If you decide to use ReadDirectoryChangesW as suggested by FindFirstChangeNotification's documentation, see this answer. Or instead, if you decide to use SHChangeNotifyRegister see this article.
Related
In my program, the creation of the main form is slow : I have identified that it hangs for around two seconds just before the form's OnCreate event is called. So I suspect this is happening while the components are created.
Since this form has several frames, I wonder if there is a way to "profile" component creation in order to see where I can improve. I suspect the lag comes from the opening of a database table that should not be open at that time (rather later, after some filtering is in place).
If there is a way get an event triggered before/after each component creation, I could do the profiling myself (with codesite for example).
Or maybe it is possible to do the component creation manually ?
Here is a quick and dirty way to work out where the delay is:
Take a copy of the Classes unit source code and place it in your project's source folder. This will ensure that this unit is compiled into your program rather than the one supplied with Delphi.
Modify the code in the constructor of TComponent. All streamed components pass through here during creation. Add code to log the class name, e.g. using CodeSite for instance.
Run your program, and then inspect the resulting log to identify the delay.
If you have many components then just knowing the class might not narrow it down. You might inject logging code into TComponent.SetName instead which will let you log the component's name. However, the basic idea is simple enough, and you should be able to apply it to your setting in order to find out the information you need.
I write an application that uses recorded data with timestamps. For this purpose I have an object that responsible to know current time (which is in the past, but still monotonic).
I wish to configure log4j2, such that printed timestamp will taken from this object and not from computer's timer. Is it possible?
Thank you.
Yes, this is possible.
You can specify system property "log4j.Clock" with the fully qualified class name of a class that implements the org.apache.logging.log4j.core.helpers.Clock interface.
See documentation here: http://logging.apache.org/log4j/2.x/manual/async.html#AllAsync
As of version RC1, this works only for Async Loggers, but in the next release this will work for all configurations. Note that in the next release the core.helpers package has been moved to core.util.
See also https://issues.apache.org/jira/browse/LOG4J2-628 for details.
Further to my post on custom format clipboard, I am considering the possibility of writing my own custom clipboad monitoring component.
Prior to the statement:
ClipboardWindow:=SetClipboardViewer(Form1.Handle);
I have seen in a sample code I studied the following snippet:
OpenClipboard(Form1.Handle);
EmptyClipboard;
CloseClipboard;
whereas others don't include a cleaning code at all. I am confused.
I believe Clipbrd.TClipboard.Clear just does the same the VCL way.
My question is:
When clearing the clipboard before joining the clipboard chain is mandatory ?
No, there is no need to clear the clipboard. Indeed, you shouldn't. Other clipboard monitors will needlessly react to the update, and the user may want to paste that thing that you just destroyed.
Additionally, there is a lot more to clipboard chain monitoring than just adding yourself to the chain. You must pass the events along to the next window (result handle from SetClipboardViewer), and you must, without failure, remove yourself from the chain when your app exits. Also, you need to avoid blocking the clipboard unnecessarily. Typically, this means waiting to register for the clipboard events until you're ready to actually process events. For example, don't make it the first thing in your startup, if you're going to subsequently open a dialog asking the user where he wants to store the data, if he has a license key, etc..
I have tips, as well as common pitfalls here:
http://www.clipboardextender.com/developing-clipboard-aware-programs-for-windows/6
The rule is as simple as possible: if you want to delete the clipboard content (so other apps can't use it) delete it. if not, keep it.
You don't know if your use wants to keep the data OR You want to implement something fancy?
Do you know those applications (Paint Shop Pro is one of them) that are asking: "You left a large image (10MB of data) in clipboard. Do you want to keep it or clear it?"
You could do something similar. :)
How would I hook into a file that's currently in use by another program, which constantly writes out to it? Let's say, there's a text file with 10 lines. When I start my app it has to detect and read any content from there on everytime the writing program saves its content. Can this be done without a constant check on the filesize/date?
You could monitor the folder for changes using the ReadDirectoryChangesW API.
Keep track of the last position you read to, and when you receive a change notification for that file, read from there to the end of the file (as it currently stands).
An example of how to use the ReadDirectoryChangesW API is here:
Why does ReadDirectoryChangesW omit events?
Kinda similar to this:
Monitor files similar to System Internal's/Microsoft's FileMon/Process Monitor
The Delphi debugger is great for debugging linear code, where one function calls other functions in a predictable, linear manner, and we can step through the program line by line.
I find the debugger less useful when dealing with event driven gui code, where a single line of code can cause new events to be triggered, which may in turn trigger other events.
In this situation, the 'step through the code' approach doesn't let me see everything that is going on.
The way I usually solve this is to 1) guess which events might be part of the problem, then 2) add breakpoints or logging to each of those events.
The problem is that this approach is haphazard and time consuming.
Is there a switch I can flick in the debugger to say 'log all gui events'? Or is there some code I can add to trap events, something like
procedure GuiEventCalled(ev:Event)
begin
log(ev);
ev.call();
end
The end result I'm looking for is something like this (for example):
FieldA.KeyDown
FieldA.KeyPress
FieldA.OnChange
FieldA.OnExit
FieldB.OnEnter
This would take all the guesswork out of Delphi gui debugging.
I am using Delphi 2010
[EDIT]
A few answers suggested ways to intercept or log Windows messages. Others then pointed out that not all Delphi Events are Windows messages at all. I think it is these type of "Non Windows Message" Events that I was asking about; Events that are created by Delphi code. [/EDIT]
[EDIT2]
After reading all the information here, I had an idea to use RTTI to dynamically intercept TNotifyEvents and log them to the Event Log in the Debugging window. This includes OnEnter, OnExit, OnChange, OnClick, OnMouseEnter, OnMouseLeave events. After a bit of hacking I got it to work pretty well, at least for my use (it doesn't log Key events, but that could be added).
I've posted the code here
To use
Download the EventInterceptor Unit and add it to your project
Add the EventInterceptor Unit to the Uses clause
Add this line somewhere in your code for each form you want to track.
AddEventInterceptors(MyForm);
Open the debugger window and any events that are called will be logged to the Event Log
[/EDIT2]
Use the "delphieventlogger" Unit I wrote download here. It's only one method call and is very easy to use. It logs all TNotifyEvents (e.g. OnChange, OnEnter, OnExit) to the Delphi Event Log in the debugger window.
No, there's no generalized way to do this, because Delphi doesn't have any sort of "event type" that can be hooked in some way. An event handler is just a method reference, and it gets called like this:
if assigned(FEventHandler) then
FEventHandler(self);
Just a normal method reference call. If you want to log all event handlers, you'll have to insert some call into each of them yourself.
I know it is a little bit expensive, but you can use Automated QA's (now SmartBear) TestRecorder as an extension to TestComplete (if you want this only on your system, TestComplete alone will do). This piece of software will track your GUI actions and store it in a script like language. There is even a unit that can be linked into your exe to make these recordings directly at the user's system. This is especially helpful when some users are not able to explain what they have done to produce an error.
Use WinSight to see the message flow in real time.
If you really want the program to produce a log, then override WinProc and/or intercept the messages in Application.
The TApplication.OnMessage event can be used to catch messages that are posted to the main message queue. That is primarily for OS-issued messages, not internal VCL/RTL messages, which are usually dispatched to WndProc() methods directly. Not all VCL events are message-driven to begin with. There is no single solution to what you are looking for. You would have to use a combination of TApplication.OnMessage, TApplication.HookMainWindow(), WndProc() overrides, SetWindowsHook(), and selective breakpoints/hooks in code.
Borland's WinSight tool is not distributed anymore, but there are plenty of third-party tools readily available that do the same thing as WinSight, such as Microsoft's Spy++, WinSpector, etc, for tracking the logging window messages in real-time.
As an alternative, to debug the triggered events use the debugger Step Into (F7) instead of Step Over (F8) commands.
The debugger will stop on any available code line reached during the call.
You can try one of the AOP frameworks for Delphi. MeAOP provides a default logger that you can use. It won't tell you what is going on inside an event handler but it will tell you when an event handler is called and when it returns.