I am developing an application for Mac OS , i need to display a information popup in Mac, In Windows OS context, it should be similar to the one, which used to be displayed near by tray-icon,
More real example is, assuming any messenger application is running, and someone form your contact list became online/available,then Messenger App display a Animated Popup near by tray-icon area,
the same use-case i am having ,
While googling i came to know, either i can make use of NSAlert or Growl , any other application that i should think.
There is no default alternatives to the Windows popup message on the Mac, but the de facto standard for doing this is through Growl. NSAlert popup messages are usually used to display exactly those: alerts. They are often to large and cumbersome to display small amounts of information well without distracting or interrupting the user. Growl, on the other hand, works well for things like these, and is what you should use.
Related
We have implemented a tablet-based application using Oracle MAF. The application runs on Windows UWP. When it was rolled out last year, it has been working fine until the customers upgraded Windows UWP on their laptops to Windows Anniversary edition. After some investigation, We found the following issues:
When user clicks on input text fields in a popup dialogue, the
application randomly crashes (not always but frequently).
When user clicks on input text fields in a normal window (i.e. not in a popup dialogue), and if the screen resolution is scaled (e.g. 150%), the
application also randomly crashes.
When screen resolution is not scaled (i.e. 100%), clicking on input text fields in a normal window
does not seem to cause crash. However, clicking on input text fields
in a popup dialogue can still cause crash.
We could not find any useful/relevant info in Windows log or in our application log.
We have also tested our application with the latest Windows Creator Edition and MAF 2.4.1, we found that the chances of random crashing seemed to have decreased, but crashing could still happen.
We have checked the Oracle MAF certification information at http://www.oracle.com/technetwork/developer-tools/maf/documentation/maf241certmatrix-3746359.html.
It states that "Any tablet or desktop running Windows 10 with Intel processor" are supported. Our customers' laptop specs are:
Lenovo Yoga with Intel Core i5 processor;
Windows 10 Anniversary Edition;
Full High Resolution screen (1920x1080)
Therefore, we believe the customer laptops provide certified runtime environment for MAF applications.
We have researched various technical forums. There seems to be little information about using MAF under Windows UWP environment.
Because our application has been used in production, and the customer corporate mandate is to use Windows 10 Anniversary edition, the customer expressed grave concerns to us for choosing MAF as the mobile platform technology, and we are now under enormous pressure to fix this issue. Any suggestions and pointers will be highly appreciated.
If you can create a reusable test case, my recommendation to you is to lodge a Service Request with Oracle Support so Oracle's development teams can look at this.
We have done further investigation on the issue "input text field causing crash on Windows 10 Anniversary Edition". This time we used the demo CompGallery application from Oracle. We navigated to the "text box" tab, clicked on the text box in "outside a form", entered some text, then clicked on "inside a form" text box. The application crashed (or repeat the above sequence a couple of times on Windows Creator Edition, the application would crash). Note by using "tab" key or screen tapping to navigate between input text fields, we can avoid crashing. With extra clicks on different input text fields before entering text, we can avoid crashing as well.
The CompGallery screen is shown below:
We then looked at the Windows log, not much details were revealed. It contains an event related to the failure of edgethtml.dll, as shown in the screenshot below.
I have a chat application written in VB.net which is used to chat between users who are connected in LAN inside a office . The application popups whenever user gets new chat message. It works fine in windows XP. But sometimes in windows 8 the application fails to popup the chat window. So my chat window is not appearing at the top when popup occurs for new messages.
I have tried using setwindowspos, form.Show(), form.BringToFront() which can bring the form to topmost. But sometimes this will not work properly.
So is there any other method other than those three(which i have mentioned above) i have used which can make the form popup and bring it to front.
Your WinForms app is a desktop application, so it's likely that the reason the pop-up is not being displayed in Windows 8 is because the desktop is not visible.
Remember that Windows 8 brings with it a whole new Start Screen interface and relegates the desktop to an alternate mode. All desktop applications still run, but they run in this separate mode and cannot interact with the new Metro applications (or whatever they're calling them nowadays). Yes, it's too bad that the usability folks at Microsoft didn't listen to Larry Tesler and have decided instead to mode us in, but c'est la vie.
So anyway, the pop-up is still being displayed, but it's being displayed on the desktop, which is not visible. Bringing it to the top isn't doing any good because it's already at the top of all the other windows on the desktop. If you click on the "Desktop" tile in the Start Screen, you should see your window.
Fixing this problem is going to take some work. Forcing a focus switch to the desktop mode is a horrible idea from a usability perspective, and I'm not sure it's even possible. A better solution would be to look into using Toast notifications instead, which can be done from a desktop application.
I've started doing Windows 8 Store app development for some projects at work, but I do not have a touch screen device of my own at home. If I write a personal app for submission to the store, I must use my own hardware since I can't use the work computers for personal projects. My concern is getting into a situation where I submit an app to the store, then have touch-screen users describing issues that I can't replicate on a non-touch-screen device.
Are there any functions or capabilities or interactions that behave differently in a Windows 8 store app when using touch vs. using only a mouse? Are there any scenarios I could encounter where I would be at a loss to reproduce or troubleshoot a user's problems if I do not have a touch screen?
As Konstantin suggested, a tablet is strongly recommended.
The next best thing is to use the device simulator in Visual Studio. It will let you change screen sizes, and allows you to simulate basic touch gestures with the mouse. This MSDN link has more info: Testing Windows 8 apps using Visual Studio 2012
Microsoft have introduced events that are pointer agnostic meaning that they should function the same way regardless of whether you are using a touchscreen, a mouse or a pen. Those are the MSPointer events. Here's some documentation. Using event handlers for these events mean that you should not be getting complaints from users about the touch friendliness of your application. However I still strongly suggest that you acquire a surface and test your application on it. Not just for the touch friendliness but also because of performance differences.
I have a game that I'm porting to the Windows Store, but unfortunately, the game genre doesn't really work well with touch input. I currently support keyboard, mouse, and gamepad, but I'm worried that I will get rejected because I don't handle touch.
Anyone have experience with this or know where I can look?
Found the answer here: Windows 8 app certification requirements
3.5 Your app must fully support touch input, and fully support keyboard and mouse input
Your app must provide visual feedback when users touch interactive
elements.
Which is a bummer because now I'm not sure how one can publish a game to the store that just doesn't make sense with touch input.
If you aren't familiar with Cinch, its an application on Mac App Store that allows you to resize ANY window to half/full screen size if you drag the window to the edge of the screen. Exactly like the functionality in windows 7.
Now my question is, how is it done? I have looked all over cocoa apis looking for notifications/delegate methods for whenever a window is being dragged (ALL windows, not just windows owned by the app from which code is running from) but can't find it. Looked in Core Graphics API...Quartz Display Services....but can't find it.
Any help will be greatly appreciated as I have been looking for the past week....Thanks!
Edit: Resize the window is easy since it can be done through applescript bridge..
Are you developer behind i-Snap or some other Mac App Store clone of Cinch?
I'm the developer behind Cinch, and while I try to maintain an "abundance mentality" which basically says "There's enough out there for everyone", I've been upset by the Mac App Store lowering the barrier for entry to this market which has produced a number of half-backed competitors.
I would be thrilled to see some real innovation around the work I have done, and not just clones looking to make a quick buck.
Anyway, you want to look at the Accessibility APIs. It's a Carbon C API. This is probably your best reference: http://developer.apple.com/library/mac/#samplecode/UIElementInspector/Introduction/Intro.html%23//apple_ref/doc/uid/DTS10000728
I've not used the Cinch app, but if I were to do this I'd expect to be using cocoa events. (Also see here) Specifically the mouse handling events, combined with where the mouse is currently on-screen. They probably set a variable when a window is grabbed and then track the mouse pointer until it hits an edge or until they release the mouse button.
Events are very powerful and provide very low level access to what is happening, but can also be very complex. Good luck!
I'm not sure. Maybe the developers combine apple script and carbon events. You can create carbon events to know when the mouse has been clicked or dragged