I accidentally touched qtspim so the error 'memory and register cleared' suddenly appears and it doesn't work.Even if I turn off the computer or re-install the program, I keep getting the same error. What should I do?
To restore the memory and the registers to regain the graphical user interface go to 'Window' in the menu bar and select restore default settings
This should return the default view and remove the error message. This has been tested on a Mac.
Related
I have created a File Explorer context menu extension that uses the IExplorerCommand interface to add menu commands to the Windows 11 context menu.
This has been working fine, but after the last Windows update, it no longer works properly.
Although the menu commands still appear, nothing happens when I click on any of them. I've added logging and I can see that IExplorerCommand::Invoke() is no longer being called.
Strangely, if I select the "Show more options" menu to get the legacy Windows 10 context menu, the commands work fine from that menu, it is only in the new Windows 11 context menu that they don't work.
I have tried running File Explorer in a debugger while selecting my menu commands, and I get lines like this in the output window when I click on the command:
onecore\com\combase\dcomrem\stdid.cxx(726)\combase.dll!00007FF9EB9947F5: (caller: 00007FF9C22E1E38) ReturnHr(2627) tid(67bc) 8001010E The application called an interface that was marshalled for a different thread.
I'm guessing this is the reason why my commands are not being called. Does anyone have any suggestions for what is causing this? Could it be a bug in File Explorer?
I've tried both STA and MTA threading models, and changing this made no difference.
Well, after wasting hours on this I finally have a solution!
My code was based on the PhotoStoreContextMenu sample code here:
https://github.com/microsoft/AppModelSamples/tree/master/Samples/SparsePackages/PhotoStoreContextMenu
This uses the Windows Runtime C++ Template Library (WRL), and defines the base classes used by the class like this:
class TestExplorerCommandBase : public RuntimeClass<RuntimeClassFlags<ClassicCom>, IExplorerCommand, IObjectWithSite>
The change that fixed it for my code was to use WinRtClassicComMix instead of ClassicCom, i.e.
class TestExplorerCommandBase : public RuntimeClass<RuntimeClassFlags<WinRtClassicComMix>, IExplorerCommand, IObjectWithSite>
I'm pretty sure this problem started when I installed KB5019509, which is the Windows update that changes File Explorer so that it now has tabs.
Note: this problem only happens for IExplorerCommands created in the plug-in for submenus, the top level commands that are defined in the APPX file work fine.
Also note that although this change does fix the problem with Invoke() not being called, it does introduce a new problem which is that IOleWindow::GetWindow() no longer works so it is not possible to get the parent HWND. (See Calling IOleWindow::GetWindow() from IExplorerCommand::Invoke() is giving error 8001010d (RPC_E_CANTCALLOUT_ININPUTSYNCCALL)).
I have been working on an app in Visual Studio 2015 (C++). It's a kiosk app for my school's tech support. Basically, it's a support site that will run in a kiosk. I need to figure out how to lock windows so it only runs that program. It would also be helpful to run the program in fullscreen mode. Keep in mind that all of the kiosks run Windows 7.
Set registry key
HKCU SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
Shell="c:\path\to\whatever.exe"
Disallow task manager via security of taskmgr.exe (add a deny read + deny execute to the binary)
Set autologn:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
DefaultUserName = whatever
DefaultPassword = whatever
Have a boot disk handy. The only way to reverse this is to boot the boot disk and undo one of the steps after mounting the appropriate hive.
you can create your program with main window in full screen mode and popup:
hWnd = CreateWindowEx(WS_EX_CLIENTEDGE|WS_EX_APPWINDOW|WS_EX_TOPMOST,
lpClsName,
"MDI Project under Visual C++ WINAPI",
WS_BORDER|WS_POPUP,
...);// add the remaining parameters
and find taskmgr.exe and hide it and start menu button and hide them also:
hTaskBar = ::FindWindow ("Shell_TrayWnd", "");
hStart = ::FindWindowEx(GetDesktopWindow(), NULL, "Button", "Start");
ShowWindow(hTaskBar, SW_HIDE);
ShowWindow(hStart, SW_HIDE);
so your program looks like easycafe or handycafe
I actually switched from C++ to C#, so I'm gonna explain my answer with C#.
I used a keyboard hook library to capture keyboard input and block all non-letter/number input so alt-f4, alt-tab etc. would not work. I then determined a closing sequence of characters using another keyboard hook (LWin+C+Home+F12+PrtSc).
As for Ctrl-Alt-Del, that cannot be disabled (as far as I know) because it is a system function, so I just left that as it is.
I also got the bounds of the screen and set the size of the window to the maximum screen size at application launch, as well as whenever the app is resized or moved. This essentially makes it so the app covers the task bar, and the bar with the close and minimize buttons is also covered, but if someone found a way to move it it would immediately go back to it's full size.
I also set up autologin as was detailed in a previous answer, but I just didn't do it through code.
I have a MFC application (Visual Studio 2010) which dynamically creates and destroys lots of editboxes, drop-down boxes, and buttons, based on the user's consequent input.
I used "Create" function to dynamically create controls, and when deleting controls the system first calls "DestoryWindow" function for each control, and then delete each control pointer.
After iterating certain amount of creating/deleting controls, if I try to "open" the dropdown menu, the system fails to open it and stops responding to my input - but I can add more controls, if I do not try to open the dropdown menu.
Could somebody please let me know how to workaround this strange issue? This one nearly drives me crazy...
Workaround is simple - don't try to "open" that menu :)
Now I assume that you want to FIX the issue. Then you need to figure out what is going on. The system may be non-responsive for multiple reasons, most likely one of these two:
You are in a busy loop in your main UI thread.
You are waiting for an event that never happens. Deadlock, for example.
When your application is frozen, try to attach debugger to it and do Debug -> Break All. Then see what code is executing. If the reason for this "freeze" will not be obvious, please post relevant code.
I have embedded VLC player into an MFC MDI application. Whenever I close the child frame which contains the embedded VLC platyer, a messagebox with the following message pops up "Encountered an improper argument". If I close the application after this messagebox pops up. It doesn't close. The application goes to background and then I have to go to Task Manager and kill the application.
This happens only in the Release build. I never encountered this error in the Debug build.
Please let me know how to solve this problem.
"Encountered an improper argument” will pop up when you try to access a control which is defined but is not part of the current scope. For example if you have several forms / views and you try to access a control from another form / view.
I would look at:
BEGIN_MESSAGE_MAP
,
DoDataExchange
and so on, and check that each ID is within the scope of the current page / view / form / dialog.
Sorry, I solved this problem. I had written wrapper class around the libmysql in my application. The problem was due to some memory leak happening in my wrapper class.
I have a "Show in folder" button which executes the following:
explorer.exe /select,"C:\dir\somefile.txt"
In Win7 this works great, a new window is always opened, but in XP, if "C:\dir" is already open, this window is reused but the selection is not changed to "somefile.txt".
This is not the expected behaviour from the point of view of the user, he expects to see "somefile.txt", but instead sees another file, and that might confuse him. At worst, he might assume that something went wrong and the file was not created.
So I need to somehow force Explorer in XP to always select the file I give it in the cmd line, or not to reuse the window.
Can anyone suggest a way to do this (different cmd parameters, maybe COM automation)?
As I don't have Windows 7, I can't confirm if this works the way you expect on subsequent Windows versions. But on my XP machine:
explorer.exe /e,/select,"C:\dir\somefile.txt"
Works exactly the way I think you'd want by opening a new explorer window each time with the right selection and avoids that confusing behavior you described.