I writing a Windows program that uses overlays (to show certain states of files). The problem is that they sometimes don't appear (without reboot), although my logs say that the IsMemberOf function executed successfully. I'm not sure if I can force overlay display, but if I can't I would like to at least display a message saying that the icons don't work until reboot.
It there anyway to programmatically tell if icon overlays are not loaded for a particular file/folder?
All my google searches have returned nothing relevant.
Related
I'm writing an application for Windows 10 to display and update text at specific locations in a Windows console window. The program is launched by a command in the console window. Upon launch, it erases the window's previous contents, then displays its output, updating as it goes, until completion. Upon exit, it should leave the displayed output in place, and a new command prompt should appear below. Launch, display, and subsequent command prompt all occur in the same console window. (Old school, I know, but that's the requirement.) The program is written in C and uses calls to the PDcurses library to control cursor placement and to output display text to the screen. The application is built with GCC/MinGW on a Windows 10 platform.
Everything works until the application exits, but then the display output disappears and the previous window contents (from before the app was launched) reappear. From what I can tell, this seems to be the default behavior for curses, possibly due to the way it handles screen buffering.
I'm looking for ways to override this behavior, but I'm not sure how to approach it. Can I direct PDcurses to write to the standard screen buffer rather than the alternate screen buffer (if that's what's going on)? If so, how? Should I copy the contents of the screen buffer before I call endwin(), then copy those contents back to the screen buffer afterward? Again, how? I'm sure this problem has already been solved, probably many times, but I haven't found any solutions that seem to apply to a C executable running in a Windows console, and I have only limited experience with PDcurses and the Windows API library. Any help would be appreciated.
The official way to do it is to set an environment variable: set PDC_RESTORE_SCREEN=0. You can combine this with set PDC_PRESERVE_SCREEN=Y to prevent PDCurses from clearing the screen at startup.
I'm trying to figure out how to prevent users of my app from snapping a screenshot of any of my app's windows. I'm mainly concerned with users automating screenshots using /usr/sbin/screencapture with cron. At first I thought there was no way to prevent it but then I discovered that there are some apps that are doing something that causes the screenshot to be all black or the color of the desktop. If I could pull that off I would be golden. I've seen other posts that touch on the subject but nothing that actually works in my situation. I'm running catalina. Any and all insights would be greatly appreciated.
Use NSWindowSharingNone of sharingType property on NSWindow
setSharingType: specifies whether the window content can be read
and/or written from another process. The default sharing type is
NSWindowSharingReadOnly, which means other processes can read the
window content (eg. for window capture) but cannot modify it. If you
set your window sharing type to NSWindowSharingNone, so that the
content cannot be captured, your window will also not be able to
participate in a number of system services, so this setting should be
used with caution. If you set your window sharing type to
NSWindowSharingReadWrite, other processes can both read and modify the
window content.
#property NSWindowSharingType sharingType API_AVAILABLE(macos(10.5));
I wonder: Is there some way of programmatically preventing the Windows 7+ taskbar from grouping an application's icons on a taskbar when multiple instances get started? I am happy with the grouping as it is, except that in one specific application of my own design I would prefer ungroupped icons.
When I came across SetCurrentProcessExplicitAppUserModelID, I was sure that was the answer - I would simply generate a new random string for each instance and that would get me a new taskbar icon. Unfortunately, it doesn't seem to work that way - even though I set a different AppUserModelID for each instance, they still get all groupped under the same taskbar icon. I would almost suspect that I got it wrong and AppUserModelID can only be used to group "unrelated" applications but not ungroup the related ones, but this article seems to indicate that my use case should work just fine.
About the only other cause of my problems which seems reasonable is the function's documentation's remark "This method must be called during an application's initial startup routine before the application presents any UI or makes any manipulation of its Jump Lists.", but as far as I can tell, I am adhering to the condition. Unless SetCurrentProcessExplicitAppUserModelID cannot be used with command-line applications because the taskbar icon gets created even before the application starts?
Is it possible to use a certain image for a loading screen when it's the first time the app is ever opened, and then after that use a different image for the loading for all visits after that?
Basically I'm creating about 10 files (not large in size) when the app is first launched and I wanted to display a message to the user so they don't think that the app normally takes more than a second to load up. I know I can display a popup on the home screen, but I have an animation that fires when you go to the home screen and also I need those files created before the user arrives there. Any ideas? Or maybe a different view point that I didn't mention?
You can't change the splash screen. Maybe you should rethink how your initial 10 files are created, and take Paul's suggestion of showing a popup control while you do the work, or better yet, offloading it into the background? I guess it depends if your created files are required for something in the UI
--edit--
Actually, the more I think about it, the more I favour a background thread doing the work while you have a popup control displayed to the user. It would allow you to give the user feedback on what is actually going on. If your popup says something like "Preparing this application for its first run...", and then shows a progress bar that updates when each file is created, the user is getting feedback on exactly why the app is taking so long to load the first time. Otherwise they may think "This app is very slow, I wonder if there is a better one out there"
I'm not sure if this is what you were thinking when you said "Popup", but you could create a full screen Popup (in the System.Windows.Controls.Primitive sense of Popup) that completely covers your main UI so that the user can't see it.
Your temporary loading UI would be defined as a UserControl described in XAML/C# in the same way as a normal PhoneApplicationPage.
When your files are ready and you close the popup you should send a message to the View (i.e. .xaml.cs) of your main page that will cause the animation to be replayed with all contents visible.
How could I detect an image on the screen and then act on that detection? For example, if I was running the script (applescript), and looked for the stackoverflow icon and loaded this page, the program would show an alert, then pause the program for 5 seconds, then go back to the original detect image script.
You might take a look at Sikuli - vanilla AppleScript does not know anything about low level stuff like images or screens.
As mentioned you can't do this with applescript. However an alternative might be to detect something on the web page itself. For example if you wanted to detect the stack overflow image at the top of this page you could do that. You wouldn't actually detect the image but you could detect the image name (or path). That's in the html code of the page, so you could check the web page code and check that text for the appropriate image name or path.
The applescript part about having an applescript to perform a task periodically is easy. You just write a stay-open applescript application that performs your task every few seconds. Then a simple variable which turns true for a successful detection would serve as a switch to make the delay happen.