Actually, I'm new to 'xamarin.mac' applications and I'm trying an application that takes screenshot frequently also captures system idle time on login.So far I've managed to capture screenshot but How to take system idle time?
I've gone through 'NSEvents'.But I cannot figure it out how to implement those
event against button click.
I just want the system idle time count that starts on login.
Related
During the working day some background process will start accessing my HD, and whilst active, this shuts down any other program I am running by perhaps 95%. This can last anywhere from 5 mins to 2 hrs. It appears to have no relation to anything I am working on and can happen at any time of the day. To find which background process out of over 100 is doing this, I tried loading Resource Monitor via resmon.exe at the Start Menu or via the button on the Performance tab in Task Manager. Both ways result in the same - the Resource Monitor starts loading its window but doesn't complete. So I am unable to access the Disk tab on it. There is an hourglass indicating it is still loading, but after 15 mins gets no further than the window frame and the top bar containing "File Monitor Help". Curiously all these three are active. Tried loading the RM whilst the HD is being accessed and whilst not. Makes no difference.
Unable to find any reference to this problem being reported anywhere.
I'm making a Clock app in swift for OS X. I have a Timer in my Clock app that works kinda like the one in iOS. My problem is whenever I put my app into the background or minimize it the application kinda freezes or stops counting after being in the background for a minute or so. It starts working right where it left off when I bring it into the foreground. Is there anyway I can make my application run in the background? I've looked and haven't found anything that works.
Thanks to anyone who can help.
Are you relying on the timer to "count" the seconds? You should only use the timer to provoke an update of the display. When the timer fires, you should check the actual time and calculate what should be displayed based on that time, not how many times your timer has fired. It should never be the case that your app "starts working right where it left off" (if, by that, you mean that it shows the same time as when it was backgrounded and starts counting up from there again).
What's probably happening is that your app is being put into App Nap. Also see the Energy Efficiency Guide for Mac Apps.
A third-party library provides a function I need to call every 100ms. Setting up a timer to do that works very well as long as my app is on foreground. When my app is on background timer works for a while but after a about a minute timer is called only after 10 second delay. The same happened when I created a separate thread with usleep-function. Is there any way I can keep timer running while my app is on background?
Use beginActivityWithOptions:reason: to disable app nap for your application.
You should try and re-architect to avoid these sorts of frequent timers, especially when your application is in the background. Making this sort of change will improve battery life for your users.
I'm writing WPF application
application targets all sort of windows and low performance computers
so I want to write launcher/splash screen for it which will be displayed before application loads
I'm not sure what language to use or what technology
I want it to be very fast and lightweight
can you suggest anything ?
Displaying a flash screen is as easy as popping up a dialog. If the dialog has the various resources such as bit maps already included then it is quite fast. However one issue that will determine this speed is how much other stuff is being initialized at application startup before the code is hit to display the dialog.
So one option would be to have a very simple application that does nothing more than display the flash screen and then start up the actual application. A simple Windows dialog application would do that. You would need to figure out how to synchronize the actual application finishing its initialization and the launching application stopping if you choose this route. There are several techniques for this and the most likely would be to use an interprocess mutex or perhaps just look for a file to be created.
For a point of sale I work with that is launched as part of turning on the terminal we ran into problems in which the application would start before some required system services such as database manager were up and running.
We have found that some environments require much more time than others so a registry variable makes it easy to tweak the delay in the field.
So as part of the application initialization what we did was that when the application starts up, it displays a dialog with a progress bar. The progress bar does a count up and we have a loop that does a one second sleep then increments the progress bar.
The number of seconds to wait is a registry setting for the application with a default value.
One problem we ran into was that when doing development and testing in a debugger, the default value was way too long for impatient programmers wanting to get started so we have condition compile so that if it is a debug compile, the delay is set to a couple of seconds. Otherwise the default is 10 seconds. However it can be changed with a change in the registry value.
See also this Stackoverflow about a launcher.
If you want something realy fast and lightweight, C would be nice.
If you dont want to learn C, you can also make a console application with .NET and C# it's fast too
Edit for comment: You can use a library like SDL wich is very fast and powerfull, and can draw images from a console application.
What am I doing wrong here? :(
I open Instruments.app, create a new UI Recorder template, select my application's .app bundle from the Target -> Choose Target menu, hit Record, open a couple of documents, type some stuff on them, close the documents, quit the app.
At this point UI Recorder stops and the Record button changes to "Drive & Record". I hit it, I see my application get launched and Instruments start recording data. Then Instruments gets confused (somehow)... my application loses focus, and suddenly UI Recorder is replaying all of my actions in Instruments!!, which just screws with Instruments in all kinds of messy ways. In this state I'm unable to move the mouse (the system just steals the cursor back), and I'm unable to quit instruments, since when I hit CMD+Q I'm prompted to Save the document, which I can't do because I have no control of the keyboard or mouse.
This is really frustrating. Has anyone got experience with this tool who can tell me where I'm going wrong? I'm scared to run it a third time as it literally hijacks my entire system.
So, you have a memory leak, and it happens when you do a specific series of actions.
The hard way to debug this would be to just have the Allocations and/or Leaks instruments and do the actions yourself every time, and every time you screw up (leave something out, do something wrong), kill the process and start over.
The easy way is the UI Recorder.
The first time you record with it, it records your actions (at the events level, not the target-action level). Mouse movements, clicks, etc.
The way UI Recorder differs from other instruments—which is why it surprised you—is that when you record with it thereafter, it plays them back.
It's not just swinging around your mouse cursor willy nilly; it's doing what you did the first time. Every time after you do things the first time, the UI Recorder does the exact same things for you.
That's what UI Recorder is for: Perfect, mechanically-ensured reproducibility. It's doing what it's meant to do; it's working as it should.
And yeah, aborting that is hard. I haven't looked yet, but there may be a stop-recording global system hotkey you can use. There is one when Instruments is in mini mode.
Also, you can set whether UI Recorder is in “drive” (playback) or “record” mode in the little pop-over that comes up when you click on the (i) button for the instrument. Switch it to record mode to re-record your interaction for different results in future runs. (I don't know whether it preserves the recording(s) in past runs.)