I have two machines: my dev machine has Windows Server 2008 R2 on it, along with Visual Studio 2008. I'm compiling my applciation on there. My other machine is the target machine and it runs Windows XP.
The problem is that I have a MessageBox call that works on the dev machine but not on the target machine.
I've commented out everything in WinMain so that it is now only this:
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow)
{
MessageBox(NULL, "Your application is already running!", "Application Notification", MB_OK|MB_ICONINFORMATION);
return 0;
}
On the dev machine the message box pops up fine (with no sound), on the XP machine everything else is fine, except that instead of the popup box I just hear the "ba-ding" popup sound.
What small setting in the bowels of MSVC++ do I need to change to get this to work on XP?
The character set I'm using is "Not Set". I'm not sure if that does anything, but I tried changing it to multibyte with no dice.
I've seen the beep-instead-of-a-window thing when there is a misconfigured manifest resource/external appname.exe.manifest so if your using one, try disabling it.
I also had this problem, and after some searching I found this solution on the web: call InitCommonControls() before you display the MessageBox. This solved the problem for me.
Like Alex K. noticed, this is caused by a manifest. If you load version 6 of ComCtl32.dll by specifying that in the manifest, you need to call InitCommonControls() on Windows XP before you can use the controls, or else they won't be loaded, and that's why you can't see the MessageBox (though you can hear it).
This is about as basic as it can get and should work on any windows system. You could check the return value of MessageBox, if it is 0, call GetLastError()
Related
I was able to get the Window Station Handle from the IIS process and get the name "Service-0x0" with GetUserObjectInformation.
Similarly, when I got the Desktop Handle from the thread and got the name, I got "Desktop".
I think there is a windowing station in the service for session 0, and no desktop.
Why does it exist?
IntPtr hWinSta = GetProcessWindowStation();
IntPtr hDesktop = GetThreadDesktop(GetCurrentThreadId());
GetUserObjectInformation(hWinSta, ...
GetUserObjectInformation(hDesktop, ...
The desktop is still there. The reason it is still there is because it is required to create windows (HWNDs) and for various APIs to function (SetWindowsHookEx etc.). The Session 0 isolation was added in Vista and too many legacy services exist to be able to fully remove the window station and desktop, these services rely on too many functions in USER32 and GDI32.
In Vista you could actually switch to the Session 0 desktop if Windows detected that a interactive service required UI input but I don't think this feature exists in current Windows versions.
I'm running Python 2.7 with ArcGIS Desktop 10.1 on Windows for Server (2 Xeon 2.13 Ghz processors).
Is it possible to suppress or automatically close the dialogue box from Windows that says "python.exe has stopped working" when python crashes? I have a continuously running, multiprocessing script that sometimes crashes for unknown reasons (working on that). When I click to close the crash report window, the script restarts and everything is okay. I want this to happen automatically until I can track down what is causing the crashes.
Thanks very much!
Doug
Procedure for disabling the Windows Debugger dialogue box found here:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb204634(v=vs.85).aspx
This prevents the debug dialogue box that requires the user to click [Debug] or [Cancel] if python crashes.
However, there is now another Windows dialogue box that says "python.exe has stopped working. Please close the program" with a button [Close Program]. Sheesh!
The dialog you refer to is part of Windows Error Reporting.
The exact method varies between editions of Windows (Windows 7 instructions here, Google will happily provide for other versions...), but if you disable this feature of Windows, your crashes will happen a lot faster(!).
This is an simply an arcpy bug. You can try to avoid using the steps that are causing the crash, but it generally happens under different tools when used to process through a long list of data.
The only workaround I have found is to make my script save its progress along the way to disk so if you restart the process, it knows where to pickup from.
If you then disable windows debugger message by altering the registry (see below), you can then just repeatedly execute the script in cmd.exe until it completes the entire batch without having to close the process manually every time in between.
I know this is an awful workaround, but it is quite uncommon to have a python library kill off the python interpreter.
DWORD HKLM or HKCU\Software\Microsoft\Windows\Windows Error Reporting\DontShowUI = "1"
DWORD HKLM or HKCU\Software\Microsoft\Windows\Windows Error Reporting\Disabled = "1"
I'm facing this problem in Windows 7. First I define a class which implements IDropTarget. Then I use RegisterDragDrop with a handle to a control placed in a window of my application. The RegisterDragDrop returns S_OK but when I drag&drop a link from Mozilla FireFox to the control, there is no call to DragEnter nor any other function of the IDropTarget implementing object. I'm so exhausted don't know what to do.
Thanks in advance
P.S: I just found out that when I run my app as administrator, this problem happens!
When I just run the application normally, everything works fine! (Perhaps does it have anything to do with changing messages filter?)
Assuming your code is correct and you've implemented your side correctly; if you're developing on Windows Vista or Windows 7, make sure you're running the application at the same privilege level as Mozilla. If you're developing in the IDE running as administrator, but run Mozilla Firefox as the logged in user, then they cannot communicate through drag-drop.
If that isn't the case, then you can try dragging files from Windows explorer to make sure your code is working correctly. It could be that Mozilla Firefox isn't using Microsoft's Ole Drag and drop subsystem correctly or at all.
I have code which looks something like this.
hWnd = CreateDialogIndirectParam(_AtlBaseModule.GetResourceInstance(), pTemplate,
hWndParent, (DLGPROC)T::StartDialogProc, dwInitParam);
This works perfectly fine in a windows XP environment, but the API CreateDialogIndirectParam() seems to crash in a windows 7 64 bit environment.
If we replace the (DLGPROC)T::StartDialogProc parameter (where 'T' is a template) with NULL, then the dialog comes up, but it does not have any contents (as expected).
This implies that this parameter is causing the crash.
Any Ideas?
If it crashes, then you should be able to check call stack at crash position. It should shed some light on the issue wit the code. CreateDialogIndirectParam API along works well.
We have SWT apps which use the setForeground method on windows XP, and they work fine. However, running the most recent stable SWT jars and dlls on Win7 seems to show the setForeground method being ignored. I know that the javadoc says it's a hint, but I wanted to know if this is because something changed between XP and 7, or if it's possible it's a system setting on my new Win7 install.
I had found this post: How to set SWT button foreground color?, but the main answer definitively says that setForeground is ignored on Windows, which isn't true in XP. Also, our problem doesn't seem to be limited to Buttons. Same issues happen with Groups as well.
Apparently, a hacky work-around exists by adding a paint listener that manipulates the GC directly to redraw the text with the appropriate color, besides being hacky, this is not practical, because it would mean we had to add this listener to the thousands places where we use Buttons.
Thanks for any help.
This doesn't have anything to do with your system settings. It's just that, as you have guessed, something has changed between XP and 7. Actually, it changed between XP and Vista. Unfortunately there is not much you can do about this, except for the hack that you have mentioned.
For more information, see this bug report.
Further investigation reveals that this is not a difference between XP and Windows 7, but rather the Classic theme vs the Aero or XP theme. If we use the XP theme in XP, Button foreground also cannot be set.