Good afternoon all!
I'm experiencing a rather annoying issue with one of my current projects. I'm working with a hardware library (NVAPI Pascal header translation by Andreas Hausladen) in one of my current projects. This lib allows me to retrieve information from an NVIDIA GPU. I'm using it to retrieve temperatures, and with the help of Firemonkey's TAnimateFloat, i'm adjusting the angle on a custom-made dial to indicate the temperature.
As FMX defaults to Direct 2D on Windows, i can monitor the FPS with any of the various "gamer" tools out there (MSI Afterburner, FRAPS, etc).
The issue i'm having is that when i put the system into sleep mode (suspend to RAM/S3), and then start it up again, the interface on my application is blacked out (partially or completely), and nothing on the UI is visibly refreshing. I'm calling the initialization for the NVAPI library regularly and checking the result via a timer, but this doesn't fix the issue. I'm also running ProcessMessages and repaint on the parent dial and it's children controls (since i can't seem to find a repaint for the form or even an equivalent).
I tried various versions of the library, and each one presents the same issue. The next paragraph indicates that this was in fact NOT the issue, and that it's actually the renderer at fault.
I have one solution, but i want to know if there's something more... elegant, available. The solution i have involves adding FMX.Types.GlobalUseDirect2D := False; before Application.Initialize in my projects source. However, this forces FMX to use GDI+ rather than Direct2D. It works of course, but i'd like to keep D2D open as an option if i can. I can use FindCmdLineSwitch to toggle this on/off dependant on parameters, but this still requires me to restart the application to change from D2D to GDI+ or vice-versa.
What's weird about it is that the FPS counter (from FRAPS in my case) indicates that there's still activity happening in the UI (as the value changes as would be expected), but the UI itself isn't visibly refreshing.
Is this an issue related to Direct2D, or a bug with Firemonkey's implementation? More importantly, is there a better method to fixing it than disabling D2D? Lastly, also related, is it possible to "reinitialize" an application without terminating it first (so perhaps i can allow the user to switch between GDI+ and D2D without needing to restart the application)?
This is may be of the issues with FM prior to the update 4 hotfix - 26664/QC 104210
Fixes the issue of a FireMonkey HD form being unresponsive after user unlock - installing this might resolve the issue for you.
The update should be part of your registered user downloads from the EDN (direct link http://cc.embarcadero.com/item/28881).
Related
When pressing the F1 key, the win32 API first sends the appropriate key message then sends a WM_HELPmessage to the control that has the focus.
As it does not process it, it gets sent up the parenting chain all the way to the form which reacts to the message.
In Delphi (XE7) this happens because of calls to CallWindowProc inside Vcl.Controls.TWinControl.DefaultHandler
While this works fine in pretty much all locations inside my applications, there is one place where WM_HELP never reaches the top form.
Trying to reproduce it, I came up with a test application that you may find here:
http://obones.free.fr/wm_help.zip
After having built the application and started it, place the focus inside the In SubLevel or Level 1 edits and press F1.
You will see that WM_HELP is caught by the form.
Now, if you do the same inside In SubLevel2 or Level 15 edits you will see that nothing is logged, the form never sees WM_HELP
Tracing in the VCL I found out that for those deep levels, the calls to CallWindowProc inside Vcl.Controls.TWinControl.DefaultHandler immediately returns on one of the controls in the hierarchy, thus preventing the form from ever receiving the message.
However, I couldn't figure out why the Win32 API code thinks it should not propagate the message anymore, except for one thing: If I remove the WH_CALLWNDPROC hook, then everything is back to normal.
You can see the effect of disabling it if you uncheck the Use hook checkbox.
Now, one will argue that I shouldn't have such deep hierarchies of components, and I agree. However, the structure in the center with two frames inside one another is directly inspired by what's in the application where I noticed the issue.
This means that it can be quite easy to trigger the problem without actually noticing it. Hopefully, in my case, I can remove a few panels and go back below the limit.
But did anyone encounter the situation before? If yes, were you able to solve it? Or is this a known behavior of the Win32 API?
This is caused by a "Windows kernel stack overflow" that happens if you send window messages recursively. On a 64 bit Windows the kernel stack overflow happens much faster than on a 32 bit Windows.
This bug also caused the VCL to not resize deeply nested controls correctly before it got fixed by changing the recursive AlignControls code to (my) iterative version (more about the stack overflow: http://news.jrsoftware.org/news/toolbar2000/msg07779.html)
We had to use CoFreeUnusedLibrariesEx for fixing a bug with heap not being cleared after using a MSXML library
Refer this link:
http://blogs.msdn.com/b/marcelolr/archive/2008/11/13/msxml-heaps-not-being-released.aspx
But this caused another issue with TTimers which takes while to show up and disappears when Delphi app is bounced and again shows after a while.
This app uses TTimers to schedule it's job like running a XML transform .
Here is the issue:
When TTimer.Enable is called it throws an error not enough Timer available.
I know this is a masked error and I would have to figure out how to get to the actual error.
This is a single threaded application with only one timer.
Here are the links I looked into
Most Common reason seems to be invalid windows handle
https://groups.google.com/forum/#!topic/borland.public.delphi.winapi/UrIskaFZggU
There are other threads that suggested that OS ran out of resources for TIMERS I'm not sure if that is relevant to me.
I'm Just trying to understand what is Interaction between CoFreeUnusedLibrariesEx and TTimers that it gradually some how robs it of resources and makes us bounce the app to get it working.
How do I go about solving this issue , I'm looking for some directions?
CoFreeUnusedLibrariesEx should not affect TTimers. But if loading and unloading a (buggy) dll leaks any user objects (this includes timers, window handles, ...) then I could imagine that you run out of user objects.
Use Windows Task Manager and configure it so it will show the "USER Objects" in the "Processes" tab. Then compare the number of user objects when you call CoFreeUnusedLibrariesEx and when you don't call CoFreeUnusedLibrariesEx.
I have a D2006 app that contains a page control and various grids, etc on the tabs. When I resize the main form (which ripples through and resizes just about everything on the form that is aligned to something), I experience long delays, like several seconds. The app freezes, the idle handler is not called and running threads appear to suspend also.
I have tries pausing execution in the IDE while this is happening in an attempt to break execution while it is in the troublesome code, but the IDE is not taking messages.
Obviously I'm not expecting anyone to point me at some errant piece of code, but I'm after debugging approaches that might help me. I have extensive execution timing code throughout the app, and the long delays don't show up in any of the data. For example, the execution time of the main form OnResize handler is minimal.
If you want to find out what's actually taking up your time, try a profiler. Sampling Profiler could answer your question pretty easily, especially if you're able to find the beginning and the end of the section of code that's causing trouble and insert OutputDebugString statements around it to narrow down the profiling.
OK. Problem solved. I noticed that the problem only occurred when I had command-line switches enabled to log some debug info. The debug info included some HTTP responses that were written to a debug log (a TMemo) on one of the tabs. When the HTTP response included a large block with no CR/LFs the TMemo wrapped it. Whenever I resized the main form, the TMemo resized and the control had to render the text again with the new word wrapping.
To demonstrate:
start a new Delphi project
drop a TMemo onto the form
align it to Client
compile and run
paste a large amount of text into the TMemo
resize the main form
I won't award myself the answer, as I hadn't really provided enough info for anybody else to solve it.
BTW #Mason - would SamplingProfiler have picked this one up - given that the execution is inside the VCL, and not in my code?
A brute-force approach that may give results.... Put a debug message to OutputDebugString() from every re-size event, sending the name of the control as the string to be displayed. This may show you which ones are being called "a lot".
You may have a situation where controls are bumping each other, setting off cascading re-size events. Like 3 siblings in the back seat of a compact car, once they start jostling for position, it can take a while for them to "settle down".
Don't make me turn this car arround....
The debug log (viewable in the IDE, or with an external ODS viewer), may show you which ones are causing the most trouble, if they appear multiple times for one "user-initiated re-size event".
Run your application in AQTime's performance profiler (included with XE, but you can get a time-limited version from their website).
Do some fanatic resizing for a while, and then stop the application.
After that, you'll see exactly which function was called many times, and where most time was spent.
I want to detect when a file date changes and update a DevX TdxMemData which is used as a Tdatasource which then would be seen in a TDBGrid that uses it.
I've found some code that uses ReadDirectoryChangesW, but seems rather complex for my simple needs.
I'm considering using a TTimer and firing it off every five seconds. (That's fine enough accuracy for me.)
Are there any caveats in doing this? I've read that Threads have all sorts of restrictions on VCL access, etc. Does the same thing apply to TTimer events?
Is there anything I need to watch out for when calling FileAge and updating a DevEx TdxMemData object while in a Timer event? Will those updates be seen by my main app?
Is there a way to detect the "state" of my program when a Timer event gets control so I can avoid problems?
Or am I opening an enormous can of worms in thinking about using a TTimer for this?
TTimer events are called within the main application thread, so there's no problems with accessing VCL objects from them. It's called when your application is idle, so it won't take place while your in an OnClick handler or anything similar unless you manually call Application.ProcessMessages.
I'd suggest using ReadDirectoryChangesW though. If you use a timer you will continue polling even if the application is idle and the file isn't changing. It will keep your CPU from going idle and keep could keep the hard drive from spinning down, which can have negative effects for power saving and battery usage.
In Demos directory there's "ShellChangeNotifier" component, which will fire events when files get modified, added or deleted inside directory. However it has only one OnChange event, so you don't know what really happened.
There's some discussion and solution about the issue in about.com
Windows lets you monitor file changes. As a jump start see http://delphi.about.com/od/kbwinshell/l/aa030403a.htm. There are several ready made components available, too. Google for "delphi monitor file change" or something similar
You can check my: DirectoryWatch
It is a wrapper around "ReadDirectoryChangesW" functions. It is more specific about changes than "ShellChangeNotifier".
When we created our program, it closed properly under XP, but under Vista, even though the program is closed, the process is often still running until I open task manager and manually kill the process.
Any suggestions on how to make sure this is closed when we close the program? What a pain.
Mark Gundy
www.magchat.com
The debugger will be your friend here. Step through the shutdown until you get stuck. That'll be the best bet.
But... assuming for some reason the debugger is affecting the behaviour, or can't be used for some other reason:
A few earlier replies suggest using FastMM. This has been the default memory manager for delphi since D2006. You can try flipping on the options to report memory leaks... but that'll only work after you've finished shutting down the process, which is what isn't working. :) So I doubt it will help you much in this case. The full version of FastMM, as opposed to the standard one packaged with delphi, might have some other helpful features... But I can't recall any that would help here.
To inspect your app while it's stuck, you could try the sysinternals tools, like Process Explorer & Process Monitor. Process Monitor may show you if it's choking on any ACCESS_DENIED errors, etc, and the stack trace at the time of the error. Process Explorer could be especially useful, by listing all the handles your process is still holding open, and allowing you to view the stack of all its living threads. A familiar function or two, in the stack traces of any hung threads, may send you hunting in the right area.
Are you using multiple threads? If one of them can't terminate for some reason, it'll hang the cleanup process.
The short answer is that you have a bug in your application. So, have you tried debugging it?
If you have the Delphi IDE installed on Vista, run the app from the IDE and break it when it 'hangs'. Chances are that you'll have a thread that hasn't terminated itself, and the VCL is waiting for it to finish.
If you don't have the IDE installed on vista, you can probably use the remote debugger, but I'm not familiar with this.
What do you call to close your program? Try using
Application.Terminate;
To force all forms to close and the process to exit.
It probably means you have some memory leak - some resource is not released.
If your application instantiates COM objects, check that you properly close them.
If you use older version of Delphi, you can try to locate possible memory leaks with FastMM
Edit, examples as requested:
I had two situations where application sometimes would stay resident in memory after exit. Both applications would disappear from taskbar, but they would be still active - visible in task manager. Both applications were created with Delphi 7.
First application has one main window with panel in which ather forms are embedded. Each form is standard TForm. Each form is created first time user requests it. Everything worked without problems in test environment, but users reported that from time to time, application would remain in memory, usually after longer usage - when user displayed almost all of the forms in application. I could not replicate this behavior while testing. That was first time I found out about FastMM. When I first run application with FastMM, it reported that some of forms embedded in main form were not released. This version was tested at user site and it turned out that 2 forms that have lots of data aware components would hang up and prevent application from exiting. When I added code that makes sure that all created forms are released before main form, application never hung up on exit.
Second example is application that uses COM to activate GIS editor (Geomedia) to manipulate some map data. I imported type libraries and created Delphi wrapper object. Some of created objects were not freed when application ends. Application icon disappeared from task bar, but application and GIS editor were still active and visible in task manager. Again, it did not happen every time application run. I included FastMM in application and it reported that some objects were not freed. I made sure that every created object gets freed and after that application did not hang on exit any more.
... and if you need to close single form, then use:
Form.Close;
GUI AND HANDLER DELETED. Reference and some parts of memory is left to provide access to variables, constants, etc.
If you need to hide ( something like Minimize, only GUI is cleared ) form, then:
Form.Hide;
GUI is cleared, leaving internal resources untoauched ( reference, handler, memory )
If form is dynamic ( created at runetime ), then use:
Form.Destroy;
ALL RESOURCES WILL BE CLEARED FROM MEMORY, leaving reference and handlers attached so you could access its location in memory.
If form is dynamic and you will not use it for the same interface, then:
Form.Free;
ALL RESOURCES, REFERENCES, HANDLERS ARE DELETED. I recommend to use this to VCL TComponent class, not for TForm class.
Also, there is Form.FreeAndNill, but my guess that it deleted all memory and loaded handlers, only allowing to use same memory space in the same interface again... (I might be wrong though).
P.S. I hope I am not writing wrong things as the last time I read the theory was a long, long time ago... and it was about Destructor DESTROY in general ...
P.P.S ALSO PLEASE BE CAREFUL if you're writing a Vista-ready app - that it includes UAC Handling with manifests / runtime code and SuperBar compatibility requirement. Also Aero requires some additional megabytes to output file due its Aero feature ... :P