Writing on MapPoint status bar - com

I'm creating a MapPoint add-in with Visual Studio 2010. I would like it to write some log messages on MapPoint status bar, to make the user know what it is doing. Is it possible? In the reference status bar it's not even mentioned. Thanks!

The documentation is pretty complete. The reason it is not covered, is because the status bar is not exposed by the API.
The only way to do it, is to try and trap Windows messages, and directly manipulate the Status Bar control. This is definitely frowned upon from a security perspective, and "prohibited" by Vista and Win7. It is also undocumented, and could easily be broken by new releases of MapPoint.
Toolbar accessibility is similar, and an often requested feature. You can switch toolbars on/off, but you cannot add your own buttons.

Related

openWorldWithSpec making it impossible to return to previous windows

Reading the book "The Spec UI framework". Trying to implement the part described in chapter "Taking over the entire screen".
After executing the code suggested in the book:
WindowExample new openWorldWithSpec
it seems to be impossible to return to previous state. Tried to delete the new WorldMorph in the inspector. Also tried with halos, as the book suggests but those buttons that are available in the halo menu don't allow it to be closed.
Is it an intended behaviour for this (to be executed to prepare an end-user environment and disable programming UI) or am I missing something?
Working in Pharo 5.0, Mac OS X version.
That is indeed intended behaviour, as part of making applications that do not allow access to the development environment anymore. But you can take a look at the code for PharoLauncher to see how you can enable a developer mode
You can actually get back to normal by:
Alt-Ctrl-Clicking on the Morph (macOS combo may be different, this is for Windows).
Clicking on the little wrench and ask for inspect.
In the evaluation pane, do:
self delete
World menu is available again.
Open a browser.
Done.
If one disables halos in settings, this is a tad harder.

OS X menubar extras + Apple HIG + UX pattern in conflict - when quit isn't quit

A quick search of Apple's Human Interface Guidelines and Developer Library yields an unequivocal guideline:
Users, and not apps, place menu bar extras in the menu bar.
Anecdotal data backs that up: submitting an app where - upon quit of a dock process/main view, the extra is left running - yields a tidy rejection.
Now - I'm a User experience designer (UXD) who typically plays, I mean, works in the mobile and web space. So please pardon my lack of Obj C chops, thanks.
I understand well the guideline and behavior/pattern: apps like Skitch, Wunderlist, Evernote, et al however very clearly leave the extra (often termed HelperApp) running in the menu bar on quit of main app. They all, do offer explicit user toggle of this w/i preferences.
There's no additional Human Interface Guidelines w/ specifics around handling this requirement for user control. Must this be included in onboarding? Dialog at 1st quit? Again: I can speak to best behavior UX wise, but my (very senior) dev wants the mandate - how are others not getting rejected?
Focus: what means of user control is/are mandated to avoid rejection?
Known/given: include in preferences
Other: ???
After hours of searching online and Apple Dev guidelines, I humbly bring this question here. There simply isn't time to play a carnival game of requirements: guess, get rejected, repeat. Thanks in advance.
Do you have a button somewhere in your user interface that adds the menu extra to the menu bar? Or does your app just do it automatically without the user telling it to do so?
I think that's the distinction, your app must only add an extra when instructed to do so. Also if the primary purpose of your app is to create a menu extra (eg, I have one that puts a calendar in the menu bar) then just launching the app is an implicit instruction, so it can be added automatically.
Ultimately, this rule really is vague and can't be clarified. What it comes down to, is that there should not be many menu extras in a user's menu bar unless the user explicitly chooses to have them. So unless your app really needs a menu extra, you must disable it by default.
If you think the reviewer should have allowed your app through then reply to the rejection explaining your position. I've had an app change to approved once after doing that.
If they still reject your app, then you can appeal the app rejection.
Alternatively, just disable the menu extra by default and have a button somewhere to add it to the menu bar.
Also, all of this assumes you are using NSStatusItem and not the "real" menu extra system — which is a private API. Only NSStatusItem menu extras can be placed in the app store as far as I know.

How does "Cinch App" do it?

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

Supress pop-up with VB 2008 Express Edition

The radio recently broke in our bedroom and as a result my missus now listen to various radio stations through her laptop. She moans that visiting various pages and clicking the 'listen' link is a bit of a pain. (Note to self: Must buy new radio!)
In the meantime, I have made a 'radio player' in VB 2008 Express, which is nothing more than 6 buttons down the left hand side of the 'player' I have created and a Web Browser Control on the right hand side.
Clicking each button links to the relevant player of the station she wants to listen to. (Being a newbie to VB and programming, I'm quite proud with what I've achieved so far!!)
Anyway, one station I do link to gives an "Are you sure you want to navigate away from this page" prompt: This one:
http://www.mygoldmusic.co.uk/
Well, thats the homepage of the site anyway, the actual player is here:
(Oops, seems I can only post one link! The actual player opens on-click of the 'listen' button then, sorry to be a pain!)
My question is: Is there a way to suppress this message in VB, or even auto-answer OK somehow?
The other sites I have linked to do not display this message, they just navigate away quite happily. Clicking OK on the prompt is no real hardship either, I hear you say, but in the interests of usability, I would just like it to navigate away from the site/player without prompting.
Remember, I'm using Microsoft Visual Basic 2008 Express Edition. (I say that, because I've come across loads of sites that tell you how to do it with JavaScript, just not VB!)
I've got to the point of thinking it can't be done, but here's hoping!
Any help/advice would be greatly appreciated. And, sorry for the lengthy question. Hope it gives you enough info on what I'm trying to achieve.
Thanks in advance again.
J.
The only way I can think of is to actually modify the DOM of the page in the WebBrowser control. That popup is loading when the "window.onunload" event fires. You should be able to override this behaviour by modifying the DOM.
The HTML document DOM (Document Object Model, essentially an object graph of the page structure) is stored in the WebBrowser.HTMLDocument property. Unfortunately, that specific property isn't available to the .NET version. It IS available to COM however, so through some very ugly and messy code you might be able to suppress the event.
The following code should be able to access the COM property containing the HTML DOM. The type returned is IHTMLDocument2, although you'll note that the class itself will return an object. You might need to add a reference to mshtml.dll to get the IHTMLDocument2 interface access the properties of this in a reasonable way.
Dim domDocument As IHTMLDocument2 = webBrowser.HtmlDocument.DomDocument
You can then access the OnUnload event (which sits on the "window" element, one above the document). Unfortunately, the plot thickens a bit here (I did say it was going to be ugly) because you need to pass a IDispatch object to the onunload event. I've never done this specifically but I found a write-up at the following link that provides some samples and should point you in the right direction: http://blogs.msdn.com/cgarcia/archive/2009/08/28/handling-dom-events-in-a-c-activex.aspx
You should be able to follow a similar approach but simply do nothing in the handler method, which should suppress the javascript alert you are getting.
Get the handle to the dialog and destroy it. Use FindWindow and send a WM_CLOSE message to it.

Code for extending the NETCF MainMenu to support background color property

I've searched for the solution to change the background color on the Compact Framework's MainMenu control, and the only answer I've found is that you need to create a custom control. Does anyone have example code for this?
I did something vaguely similar where I wanted to handle the WM_EXITMENULOOP message which was not available as an event in .NETCF.
The solution was to "subclass" the Main Menu, an old MFC trick where you replace the WndProc function with your own, handle any windows messages (WM_EXITMENULOOP in my case) and call the base class WndProc for everything else.
Some sample code is available on Alex Yakhnin's blog on how to subclass a control:
Example of subclassing a window in .NETCF
In your case you'd actually be subclassing the Form that the MainMenu resides on, and I think WM_DRAWITEM would be the windows message you'd want to handle yourself.
I haven't tried changing the background color myself so not totally sure this will work, but subclassing would be where I'd start.
There is no way of doing this.
Your right in that you'll probably need to create your own control.
This was something I was considering doing anyway to make the application go on Windows CE and Windows Mobile.
The problem with adding menus when the application needs to work with both is that the menu goes to the top of the screen on Windows CE and covers any controls that might be there.
It would be less hassle in the long run just make a new control.
I tried to do something similar a while back and discovered that you have to write your own menu; essentially from scratch. I gave up because the project I was working on couldn't afford the expense. I also discovered that OpenNETCF has a pretty awesome menu control. I don't know if it's included in their free software, but it might be worth looking into.