Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
General
GeneralPortable MacsHardwareNetworking
Applications
Mac ApplicationsEudoraFirefox / MozillaInternet ExplorerOutlook ExpressMS OfficeEntourageExcelPowerPointWordVirtual PCMedia PlayerOther MS Products
Programming
Mac ProgrammingCodeWarriorPerl
Country Specific
Australian Mac GroupUK Mac Group

Mac Forum / Programming / Mac Programming / May 2008



Tip: Looking for answers? Try searching our database.

What's the substitute for WriteLocation?

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Daryle Walker - 28 May 2008 21:28 GMT
I've been curious about the geographic location functions, ever since
the pre-X days.  Back then, the location was stored in PRAM, read/
written by users with the "Map" control panel, and read/written by
developers with the "ReadLocation" and "WriteLocation" API.  What is
the modern equivalent?

(I'm stuck on Tiger and I'm using Apple's developer docs on the web.)
Looking at the Carbon Memory Managment Utility Reference,
"ReadLocation" is still usable, but "WriteLocation" has been
depreciated since Mac OS X 10.0 (i.e. killed since the X series), with
the very concept of changing this information banned.  This is hope in
the Carbon Date/Time/Measurement Utilities Reference, that claims that
geographic location can be set with the assistance of the
Authorization APIs.

Of course, reading up on the Authorization API only tells how to use
the APIs in general, it does _not_ give the specifics needed:

1. The appropriate rights IDs
2. Where the data is stored/accessed
3. What format the data is in
([2] and [3] don't need much explanation if you're supposed to
authorize somehow, then use the existing "WriteLocation" API.)
4. Which versions of Mac OS X is this technique valid

Can anyone help me here?  Or is there no answer, and a bug needs to be
filed?  At least some answer can help someone else in the future when
Google-ing for a solution.

Daryle Walker
Ben Artin - 29 May 2008 03:45 GMT
> I've been curious about the geographic location functions, ever since
> the pre-X days.  Back then, the location was stored in PRAM, read/
> written by users with the "Map" control panel, and read/written by
> developers with the "ReadLocation" and "WriteLocation" API.  What is
> the modern equivalent?

There is none. All you can deal with in Mac OS X is the timezone.

Ben

Signature

If this message helped you, consider buying an item
from my wish list: <http://artins.org/ben/wishlist>

Simon Slavin - 30 May 2008 22:35 GMT
On 28/05/2008, Daryle Walker wrote in message <0eb229ef-4fb8-4dd8-a7d4-
21729ccdef97@25g2000hsx.googlegroups.com>:

> "ReadLocation" and "WriteLocation" API.  What is
> the modern equivalent?

There isn't really a modern equivalent to those functions.  In fact,
there's no idea that every Macintosh should know where it is in the world.
In some ways it's a great idea.  It would certainly look really neat for
instant messaging programs to be able to show you where your
correspondents are on a world map.  In other ways, I can see that there
are security risks.

The good news for you is that the iPhone is driving location information,
with some stuff in the next version of the iPhone OS that we can't talk
about for another ... erm ... few days.  Nevertheless several people are
posting about it on the web, so google for

"Core Location Framework"

and read on.  The logical thing would be to include the same framework
into the OS for Macintoshes -- whether or not each Mac is equipped with hardware that can secure the location automatically.  So you may just be a little early with your question.

Simon.
Signature

http://www.hearsay.demon.co.uk

 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.