I'm using PCSCConnector from http://nobbi.com, last update - April 2004.
All work fine with Windows XP but with Windows 7 there has been some trouble.
When I press CTRL+F2 in the Delphi IDE (terminate) and a card connection had been opened by my software then any software (including my own) can't open a new connection to the card. I need to physically reconnect the card (USB in my case) to be able to create new connections to it.
I try to change dwScope in SCardEstablishContext to SCARD_SCOPE_SYSTEM (from SCARD_SCOPE_USER) and dwDisposition in SCardDisconnect to SCARD_LEAVE_CARD (from SCARD_RESET_CARD) but the problem persists.
When you use Ctrl+F2, it's a forceful termination. No code gets a chance to properly clean up, close things, or free anything - it's just shut down. No changes you make to the library's exit code is going to help, because it never gets a chance to run. You've stopped that from happening by forcefully terminating the app.
The solution: Don't use Ctrl+F2 for anything except runaway code you can't stop any other way. Close down your application normally the way it's supposed to be closed down, so it has a chance to clean things up and call finalization code and so forth.
Related
We're in the process of moving a slew of our applications from Windows XP to Windows 7 and have run into an old problem with Word Automation.
We had an issue in one of our applications where we would get "Call rejected by Callee" when trying to connect to Word, unless it was already open. We worked around it in Delphi 2000 / Windows XP with the following code:
WordApp.Connect;
WordApp.Visible := True;
WordApp.Documents.Add(Template, EmptyParam, EmptyParam, EmptyParam);
WordApp.ChangeFileOpenDirectory(jdir);
WordApp.Visible := False;
WordDoc.ConnectTo(WordApp.ActiveDocument);
This no longer does the trick under Windows 7 - and recompiling under XE2 doesn't seem to help.
I've seen a related question here which pertains to Visual Studio - anyone know how to apply that to Delphi (XE2 would be fine at this stage)
Dan
"Call rejected by callee" errors happen when the instance that you are connected/connecting to is currently in an interactive mode: an open dialog for example. Or, in Excel, a cell being edited, or even being in a state where a cell being edited was interrupted by the user switching away from the application - when (s)he returns it may look that the edit was completed, but the interactive mode is not ended until a different cell is selected.
Because of this I don't understand why you were getting this error when connecting unless another instance was already open. If there is no instance open (and visible), Word cannot be in interactive mode and you shouldn't have been getting the error. Is it possible your remedy merely circumvented the real problem?
No matter what though, you are in a situation where you are trying to connect to an instance that is in interactive mode. Either beforehand, or caused by your code. As you switched from XP to Windows 7, UAC does come to mind as a possible culprit.
I'd do away with the work-around, and see where that takes you.
For Word automation I always make sure that:
I connect to a dedicated instance by using a ConnectKind of ckNewInstance and
make sure I do not make my dedicated instance visible or
make sure I only make it visible after I am all done and can turn the instance over to the user.
If you have no option but to automate against a visible (and thus non-dedicated) Word instance, you will simply have to deal with the possibility of this error coming up. When it does, alert the user to what is happening and make sure you offer a retry.
Update
The thread on the Embarcadero forums mentioned in the comments by #Hendra includes a link to some very useful MSDN documentation: Fixing 'Application is Busy' and 'Call was Rejected By Callee' Errors
I have an odd intermittent crash that only occurs under some circumstances that I am having trouble solving, and I'm seeking SO's advice for how to tackle it.
The bug
At apparently random points, Windows shows the "[App] has stopped working" dialog. It is an APPCRASH in ntdll.dll, exception code 4000001f, exception offset 000a2562. Here's where it gets tricky: this only occurs when running the application under the debugger. However, the debugger does not catch this exception, and at the point where Windows shows this dialog, the IDE is not responding. This bug does not occur when running normally, i.e. not within the IDE debugger.
I can't reproduce it outside the debugger, so I can't run the program and attach when it's already crashed. I can't pause execution when Windows shows this dialog, since the IDE isn't responding. I can manually trace through lines of code to see where it occurs. There are several, and where it occurs is apparently random. For a while it occurred when showing a window (or new form), for a while when creating a thread.
Edit: I have tracked it down to the IDE: if I pause on a breakpoint and click the Thread Status tab, the program will crash immediately with the above dialog even though it is, theoretically, paused. In this situation, the IDE remains responsive. This is really weird.
More information
I have just moved my development environment to VMWare Fusion. The bug also occurs running a build from my old (native Windows) computer on my new computer; it did not occur with the same EXE file on that old computer. This makes me wonder if it is related to Fusion or something in my new setup.
I am running:
Windows 7 Pro x64 on WMWare Fusion 3.1.3 on OSX Lion 10.7.1, all fully updated. Fusion is running in "Full screen" mode on one of my screens.
A colleague running Windows 7 natively (not in a VM) does not encounter this issue. Nor did I on my old Vista computer.
Embarcadero RAD Studio 2010, fully updated (I hope; there are about five updates and getting them all in order is tricky.) I have DDevExtensions 2.4.1 installed, and the latest IDE Fix Pack too: uninstalling both these has no effect.
The application is written mostly in C++, with snippets of Delphi. It is 32-bit.
We use EurekaLog, but the exception is not caught by it either. (Normally, an exception would be caught first by the debugger, then by EurekaLog.)
Running a debug build (no EurekaLog, extra debug info etc, debug DCUs set to true) also reproduces it. However, the "Debug DCUs" option on The Delphi Linking page of the C++Builder project settings dialog seems to have no effect - I can't step into the VCL code and find the line that actually triggers the error.
Codeguard (which detects memory access errors, double frees, access in freed memory, buffer overruns, etc) reports nothing.
This has all the hallmarks of a memory corruption. It only appears when you run under a one particular environment, and occurs at a different location each time. Both classic symptoms.
The best way I know to debug this is to download the full FastMM and run with full debugging options enabled.
If that doesn't help then you are reduced to removing parts of code, one by one, until you can isolate the problem.
Another problem I have seen in D2010 is a problem when mixing local class definitions (i.e. class inside class) with generics. The code generated is fine but the debug DCUs are wrong and when stepping through the code the debugger jumps to the wrong file and dies shortly after. You don't seem to have quite the same problem but there are similarities in the IDE deaths.
Finally I would advise you to suspect your own code rather than VMware. It's always tempting to blame something else but in my experience, whenever I have done so, it was always my code in the end!
I hit a quite similar problem. I've also been developing a .dll and when I've set a breakpoint anywhere in my code, Delphi stopped at the source code line and the host-application crashed immediately.
Closing the "Thread Status Window" in debug layout "fixed" the problem.
I'm working on Windows 7 64-bit and Delphi XE3.
4000001F is STATUS_WX86_BREAKPOINT
In other words, it is INT 3, which was not handled by IDE.
Since it is raised in NTDLL - I would guess that this is indication of memory corruption in system heap. Remember, some Windows code would switch to debugger version when running under debugger. That's why you can not reproduce this when application is running as standalone outside of the debugger - because breakpoint is not generated.
You may try FastMM in full debug mode, but I do not think that it will help you. The corruption does not happen in your memory, it happens in system memory. Yes, perhaps memory allocation scheme will be changed - and your corruption will reveal itself in your code/memory... may be. Try use top-down allocations, try use SafeMM...
Another possible approach would be using Application Verifier.
See also:
Windows has generated a breakpoint
C++ error on Ms Visual Studio: "Windows has triggered a breakpoint in javaw.exe"
http://blogs.msdn.com/b/oldnewthing/archive/2012/01/25/10260334.aspx
http://blogs.msdn.com/b/oldnewthing/archive/2013/12/27/10484882.aspx
Check the The projects dsk file and make sure it does not have a reference pointing to the wrong unit. The fix is to open the dsk in an editor and change the file location to the correct location.
I have a backup app that will close user-defined running programs before the backup so that open data files can be closed and flushed before the backup. After the backup is complete it restarts the programs in the list.
I have no problem getting the window Handle using the Caption and PostMessage(AppHandle,WM_CLOSE,0,0); That works fine for most apps, but not for ones running in the Notification Area (System Tray)
Currently I am using TerminateProcess( and it works for those Notification Area apps, but it leaves files open as Windows bypasses any Close instructions and just slams those apps down.
I have searched long and hard and I cannot find a nicer way to shut down Notification Area apps. Can anyone please help?
Thanks
In order to close a program gracefully, you need to know something about how that program expects to be closed. If closing the main window accomplishes it, then you need to know how to recognize the "main" window.
Programs don't run "in" the notification area. They display icons there. Any program with a notification icon must also have a window (because the shell tells the program that the icon has been clicked by sending messages to the window). Even if the window isn't visible, it still must exist. If you can determine some set of properties that identify the window associated with a particular notification icon, then you could close it. There is no standard set of attributes to look for, though; each program can do it differently.
And even if you find the window you're looking for, closing it might not be the way the program expects to be terminated, either. It might expect a certain command from the notification icon's menu instead, or some message sent by a dialog box that the program displays.
If your application is running on Windows Vista or Windows 7, don't shut down programs - instead use the Volume Shadow Copy service to access a snapshot of the files while they are still in use. This is what the Windows 7 built-in backup program does.
If you're on an earlier version of Windows, there's no foolproof solution. If the program has a systray icon, it will have a hidden window as well, and you can try sending WM_QUERYENDSESSION and WM_ENDSESSION to it. However, there is no guarentee that the program will shut down, and if it does shut down, since you may be bypassing parts of its normal shutdown process, it may not complete its normal cleanup. There may also be programs running with no associated windows at all. The best approach would probably be to simply log off the user, and perform the backup from a service process. Of course, you'll still have sharing issues with files opened by other services...
After reinstalling Delphi (and installing the Update 1 on top of it) it needs 19-20 seconds to start.
In the beginning it shows nothing (about 17 seconds).
Then it finally shows the splash screen and the modules it loads. I already have DelphiSpeedUp plugin.
How can I make is start faster? Or is this the typical loading time for Delphi XE with Update 1?
Update:
'Process monitor' shows that Delphi accesses the HKLM\system\currentControlSet\Services\TcpIp\Parameters and stays there to about 10 seconds. No other registry key or file is accessed after this, for 10 seconds!!!!!!!
Probably is the Embarcadero's protection that tries to 'call home'. I guess I have to unblock Delphi in my firewall. Maybe if it can call home it will load faster.
Also, does anybody tried to make Delphi XE .Net free?
20 seconds for click-on-icon to IDE-ready-for-input?
Don't change anything! I wish mine was as fast as that!
I was so damn right!!!! By default, my firewall block all programs except Firefox and Thunderbird. So, I let Delphi XE call home and guess what: It loaded in 10 seconds!
With the firewall off it connected to two different IP addresses and exchanged some data.
One of the addresses is server155.autometadqa.com (64.34.176.155:80).
Probably I will have to install some network package tracker to see what kind of data it sent out of my computer and in which qualities (KB, MB).
Solution1-Make Delphi fast
Let Delphi through the firewall.
Solution2-Keep computer isolated from internet
Don't let Delphi through the firewall.
I know absolutely nothing about Embarcadero except that they make Delphi now. But since they had money to buy it, it means it is a big company and because of this case, also respectable. So, I will let Delphi through the firewall in order to cut those 20 seconds to 10.
Try to add following line in your HOSTS file:
127.0.0.1 server155.autometadqa.com
Repeat this for all servers if there are more then this one.
Is Delphi phoning home, or is it checking for updates?
What happens if you change your firewall setting back and simply turn off the check? In XE, the registry key is:
HKEY_CURRENT_USER\Software\Embarcadero\BDS\8.0\AutoRun\UpdateCheck
You can disable the auto-update, if indeed that is the cause of the delay, by removing these registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\CodeGear\BDS\7.0\AutoRun\UpdateCheck
HKEY_CURRENT_USER\Software\CodeGear\BDS\7.0\AutoRun\UpdateCheck
I'm not sure that you need to remove both, but I always do. And this is for a 64 bit machine. On a 32 bit machine you need to remove:
HKEY_LOCAL_MACHINE\SOFTWARE\CodeGear\BDS\7.0\AutoRun\UpdateCheck
HKEY_CURRENT_USER\Software\CodeGear\BDS\7.0\AutoRun\UpdateCheck
I do this because the auto-update doesn't play nice with UAC on Delphi 2010 (perhaps they fixed that in XE) and in any case, I don't like the idea of my production compiler changing without my consent.
This is driving me crazy. I'm not going to take it anymore. I'm going to ask, even at the risk of eternal public humiliation! (If it's something really obvious or that I've done to the system myself).
For reasons I've never quite had the patience to work out, every so often the form I'm working on in Delphi 2007's visual form editor goes 'pseudo-read-only'; I can add new components to the form, I can move/resize existing ones (and change any properties in the Object Inspector), and I can select a component and 'copy' it to the clipboard.
But I'm completely unable to cut a component from the form, or paste a new copy down. I don't believe it's to do with the 'Lock Controls' Edit menu option as I can toggle this on or off and it has the effect it's supposed to - this disappearance of Cut & Paste happens on the right-click context menu, from the keyboard and from the main Edit menu - it's as if the form has become read only to thing to do with the clipboard.
If I close the form in the IDE and then reopen it, everything starts working fine again (just as D1, D3, D5 and D7 always did for me, previously).
I'm not going mad, as I'm sure I read something about why this happens on a newsgroup once and it's caught me out from time to time many many times in the last few months, but I've failed to find the newsgroup reference this evening and I've decided that, as more and more Delphi users seem to be making use of StackOverflow, it was worth asking here.
Help - when I'm doing lots of form-work it drives me absolutely mad!
you can try to download the clipboard monitor application to see if anything is messing with your cut/paste. I have noticed simular problems when running in a VM, the VM gets confused as to what is in the clipboard and won't let me cut/paste again until I go back to my host application open something else (notepad works fine) and copy something fresh. I think thats more a problem of the other clipboard monitoring applications on my system than anything else.
I'm using copy/paste "desing" a lot, but they never went away.
Are you using some other IDE addins that mandle with copy/paste?
I think it is a known bug in the IDE, but I can't seem to find any references to it. I also have experienced this problem. You might want to try IDE Fix Pack, although it does not claim to fix this problem.
Check that other apps can use the clipboard too. Sometimes I am paused in the middle of a clipboard operation in my app, which stops other apps opening the clipboard. Can be confusing!
The virus detector app: Webroot SecureAnywhere stopped pasting from working - when I disabled this dumb virus detector - all was good again.
I think you should try the Desktop Settings. I had the same issue and after changing the Setting to Debug, Cut/Copy started working.