I'm trying to use NSUserNotificationCenter. I'm able to deliver notifications successfully. I'm using the ShouldPresentNotification callback on NSUserNotificationCenterDelegate to present notifications, even when the app is running in the foreground.
This works great, except on one of my machines!
I have stripped the code down to it's most basic example. All my machines are running 10.8.3 and Mono 2.10.12. On my 2008 Macbook Pro and a colleague's 2012 rMBP, everything works as excepted. However, on my identical 2012 rMBP the notification is not presented if the app is in the foreground. In fact, on this machine, and this machine only, none of the NSUserNotificationCenterDelegate methods are invoked.
Note that the notification is still delivered on this machine - the notification works - it just doesn't get presented when the app is in the foreground (because the delegate methods are never invoked).
I would really appreciate if anyone has some insight on what settings or configuration might causes this behaviour, or if there is some mechanism I can use to debug this behaviour.
Here is my code:
UNCShouldPresentNotification ShouldPresent = (a, b) => { return true; };
// Shared initialization code
void Initialize()
{
NSUserNotificationCenter.DefaultUserNotificationCenter.ShouldPresentNotification = this.ShouldPresent;
}
partial void notify(NSObject sender)
{
DoNotify();
}
[Export("doNotify")]
private void DoNotify()
{
NSUserNotification notification = new NSUserNotification();
notification.Title = notificationText.StringValue;
NSUserNotificationCenter.DefaultUserNotificationCenter.DeliverNotification(notification);
}
Ok we had exactly the same bug.
Firstly we contacted Xamarin and they've fixed it in the most recent code.
Secondly it was due to overriding BOTH the Delegate delegate (great name I know) and the ShouldPresent setting.
If you want to override the ShouldPresent setting, do this in your NSUserNotificationCenter.Delegate instead.
I hope that's clear. We've a resolved bugzille entry at https://bugzilla.xamarin.com/show_bug.cgi?id=11456
This now works, somewhere between updating MonoMac, Mono and OS X on my machine.
Related
I have a UWP application.
And i have a need to change locale on the fly, so i have this for language changing:
Windows.Globalization.ApplicationLanguages.PrimaryLanguageOverride = language.FourDigitCode;
ResourceContext.GetForViewIndependentUse().Reset();
ResourceContext.GetForCurrentView();
But there is a problem that system features language doesn't switch ( only after application relaunch ) how can i fix it?
Here is an example:
Now i run this code:
Windows.Globalization.ApplicationLanguages.PrimaryLanguageOverride = "lv-LV";
ResourceContext.GetForViewIndependentUse().Reset();
ResourceContext.GetForCurrentView();
The UI gets localized, but system features still remain unlocalized:
But when i restart the app, all is OK:
Any ideas how can i fix it?
I'm afraid there is no fix for this and what you've seen is by design. Ref Remarks of PrimaryLanguageOverride property:
When you set the PrimaryLanguageOverride, this is immediately reflected in the Languages property. However, this change may not take effect immediately on resources loaded in the app UI. To make sure the app responds to such changes, you can listen to the QualifierValues property on a default resource context and take whatever actions may be needed to reload resources. Those requirements may vary depending on the UI framework used by the app, and it may be necessary to restart the app.
For your scenario, a restart is needed. I'd suggest that you can add a tip to tell users to restart the app and also a button to close the app like what used in News App.
And to close the app, we can call Application.Exit method like the following.
Application.Current.Exit();
Maybe page reloading can fix it? Try to re-navigate to the same page.
Found the example below here.
//like this
private bool Reload(object param = null)
{
var type = Frame.CurrentSourcePageType;
Frame.Navigate(type, param);
Frame.BackStack.Remove(Frame.BackStack.Last());
}
// or like this
private bool Reload(object param = null)
{
var frame = Window.Current.Content as Frame;
frame.Navigate(frame.CurrentSourcePageType, param);
frame.BackStack.Remove(frame .BackStack.Last());
}
I've noticed the following error popping up in the console when running my app on iOS 9 when using a storyboard. I'm using xCode7. Is this something I need to be concerned about?
-[UIApplication _handleNonLaunchSpecificActions:forScene:withTransitionContext:completion:] ** unhandled action -> <FBSSceneSnapshotAction: 0x176bfb20> {
handler = remote;
info = <BSSettings: 0x176a5d90> {
(1) = 5;
};
}
There is nothing wrong with your code. This is a logging message internal to Apple, and you should file a radar about it.
There are two hints that show that this is probably Apple's code:
The underscore leading the method name _handleNonLaunchSpecificActions:forScene:withTransitionContext:completion is a convention indicating that the method is private/internal to the class that it's declared in. (See this comment.)
It's reasonable to guess that the two letter prefix in FBSSceneSnapshotAction is shorthand for FrontBoard, which according to Rene Ritchie in "iOS 9 wish-list: Guest Mode" is part of the whole family of software related to launching apps:
With iOS 8, Apple refactored its system manager, SpringBoard, into several smaller, more focused components. In addition to BackBoard, which was already spun off to handle background tasks, they added Frontboard for foreground tasks. They also added PreBoard to handle the Lock screen under secure, encrypted conditions. [...]
I have no idea what the BS prefix in BSSettings is for, but
BS is shorthand for BackBoard Settings, and an analysis of this log message would indicate that it's not anything you did, and you should file a radar with steps to reproduce the logging message.
If you want to try and grab a stack trace, you can implement the category linked to here. Some would argue that overriding private API is a bad idea, but in this case a temporary injection to grab a stack trace can't be too harmful.
EDIT:
But, we still want to know what this action is. So I put a breakpoint on -[UIApplication _handleNonLaunchSpecificActions:forScene:withTransitionContext:completion] and started printing out register values and found a class called FBSceneImpl which had a whole bunch of information about my application:
We are able to find out which private method is called next (stored in the program counter, instruction pointer, register 15.)
I tried finding the un-handled FBSceneSnapshotAction referenced in the log, but no dice. Then, I subclassed UIApplication, and overrode _handleNonLaunchSpecificActions:forScene:withTransitionContext:completion. Now I was able to get at the action directly, but still, we don't know what it is.
Then, I looked at the FBSceneSnapshotAction again. Turns out it has a superclass called BSAction.
Then I wrote a tool similar to RuntimeBrowser and looked up all of the subclasses of BSAction. It turns out that there's quite a list of them:
The two method names we have (one from the log and one from the program counter on the devices) indicate that these actions are used under the hood for passing actions around the system.
Some actions are probably sent up to the app delegate's callbacks, while others are handled internally.
What's happening here is that there is an action that wasn't handled correctly and the system is noting it. We weren't supposed to see it, apparently.
AFAIK, the info above is related to iOS during snapshot the screen (i suppose for double click home multitask related behaviour).I deeply investigated my application and seems that it does not get any side behaviours. You can safely ignore it, for now.
You can use the following gist simple category to test yourself against the calls to the above function:
I have figured it out, it will happen when you have IBAction method declared in .h or .m file but you have not bind it to any control.
.m example:
- (IBAction)click:(id)sender{
}
but not assigned this method to any control in storyboard.
haven't find out why it happens in my app, but at least you can catch the exception, if you want to keep this from popping up in your log pane. It's not a solution, but it might give you more insight why it is happing by inspecting any of the arguments that are passed in the catch.
swift 2 version:
import UIKit
extension UIApplication {
func _handleNonLaunchSpecificActions(arg1: AnyObject, forScene arg2: AnyObject, withTransitionContext arg3: AnyObject, completion completionHandler: () -> Void) {
//whatever you want to do in this catch
print("handleNonLaunchSpecificActions catched")
}
}
I created a fullscreen app with the following to hide the mouse...
// need this hack to hide the mouse for AIR for some reason...for OSX
// http://blog.formatlos.de/2008/11/16/air-hiding-the-mouse/
stage.nativeWindow.activate();
stage.nativeWindow.orderToBack();
stage.nativeWindow.orderToFront();
Mouse.hide();
This works on my machine at home running OSX Lion...but when this is installed on the client's machine (also running OSX...I need to find out the version), the mouse does not hide?
When I take out the 3 line hack before the Mouse.hide(), the mouse does not hide on my machine. Will test this out on the client's machine too.
Anyone experience this before?
Are you including flash.ui.Mouse in your code?
import flash.ui.Mouse;
Take a look in this site: http://samhassan.co.uk/2008/10/08/air-10-mousehide-work-around/
You could try to hide mouse cursor when the first enterFrame event is fired. Some elements are not fully available till the first frame is build:
// i.e. on main app initilize event handler
addEventListener(Event.ENTER_FRAME, onEnterFrame);
private function onEnterFrame(event:Event):void {
Mouse.hide();
removeEventListener(Event.ENTER_FRAME, onEnterFrame);
}
This way, you have not to rely on hacks or workarounds.
Is there any way to call App Expose in Lion programmatically, for example on an event tap, etc?
If you don't mind using a TOTALLY UNDOCUMENTED API, which might change at any point without notice:
void CoreDockSendNotification(CFStringRef, void *);
(...)
CoreDockSendNotification(#"com.apple.expose.front.awake", NULL);
Other known arguments are #"com.apple.expose.awake" and #"com.apple.dashboard.awake", which activate Mission Control and Dashboard, respectively. #"com.apple.showdesktop.awake" used to activate Show Desktop, but no longer works on current versions of macOS.
Note that most applications should not use these calls -- these actions are intended to be invoked directly by the user.
Expose does not exist in Lion, it has been merged with Spaces into the Mission Control application.
You can launch Mission Control:
[[NSWorkspace sharedWorkspace] launchApplication:#"Mission Control"];
I'm porting an archaic C++/Carbon program to Obj-C and Cocoa. The current version uses asynchronous usb reads and GetNextEvent to read the data.
When I try to compile this in Objective C, GetNextEvent isn't found because it's in the Carbon framework.
Searching Apple support yields nothing of use.
EDIT TO ADD:
Ok, so what I'm trying to do is run a document scanner through USB. I have set up the USBDeviceInterface and the USBInterfaceInterface (who came up with THAT name???) and I call (*usbInterfaceInterface)->WritePipeTO() to ask the scanner to scan. I believe this works. AT least the flatbed light moves across the page...
Then I try to use *(usbInterfaceInterface))->ReadPipeAsyncTO() to read data. I give this function a callback function, USBDoneProc().
The general structure is:
StartScan()
WaitForScan()
StartScan() calls the WritePipeTO and the ReadPipeAsyncTO
WaitForScan() has this:
while (deviceActive) {
EventRecord event;
GetNextEvent(0,&event);
if (gDataPtr != saveDataPtr) { // more data up the timeout
timeoutTicks = TickCount() + 60 * 60;
saveDataPtr = gDataPtr;
}
if (TickCount() > timeoutTicks) {
deviceActive = false;
}
}
Meanwhile, USBDoneProc incrementing gDataPtr to be the end of the data that we've read so far. It gets called several times during the asynchronous read, called automatically by the callback, as far as I can tell.
If I cake out the GetNextEvent() call in the WORKING code the USBDoneProc doesn't get called until the asynchronous readpipe timesout.
So it looks to me that I need something to give control back to the event handler so that the USBRead interrupts can actually interrupt and make the USBDoneProcget called...
Does that make any sense?
thanks.
I suppose the nearest thing to a Cocoa equivalent would be -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]. But bear in mind that GetNextEvent is archaic even for Carbon. The preferred way of handing events is the "don't call us, we'll call you" scheme, where the app calls NSApplicationMain or RunApplicationEventLoop and events are dispatched to you.
EDIT to add: Does you app have a normal event loop? If so, maybe WaitForScan could start a Carbon timer and return to the event loop. Each time the timer fires, do what you did in the WaitForScan loop.
there is a USB hidapi that works for mac on windows.
http://www.signal11.us/oss/hidapi/
may this could be of help to you?
It works fine (I can list the connected USB devices and connect/write/read to a device);
however, if i USB device is connected/disconnected during the runtime of the application, I don't see the new connected/disconnected devices.
See: https://github.com/signal11/hidapi/issues/14
If I add the following code to hidapi, then hidapi detects the new USB devices.
#include <Carbon/Carbon.h>
void check_apple_events() {
printf("check_apple_events\n");
RgnHandle cursorRgn = NULL;
Boolean gotEvent=TRUE;
EventRecord event;
while (gotEvent) {
gotEvent = WaitNextEvent(everyEvent, &event, 0L, cursorRgn);
}
}
I need to compile this on OSX10.5 because it uses Carbon instead of Cocoa.
I am currently looking how to transform this to Cocoa.
you are also trying to move your code to cocoa, right?
let me know if you find out; I'll post it here if I get it.
regards,
David
Have you considered throwing the whole thing out and using Image Kit's new-in-10.6 scanner support instead? Even if it's custom, writing a TWAIN driver for it might be easier (and is certainly better) than trying to twist Cocoa into a GetNextEvent shape.