Apple was less of a threat to M$ in 2004
Don't worry. Apple still is no threat to Microsoft.
Apple was less of a threat to M$ in 2004
True delegate support comes to mind as well as public folders and other things.
My understanding is the Spaces issue is more on the Apple Side than the MS side, but regardless, the end result is that it doesn't work![]()
No worries mate, Snow Leopard's on it's way. It will fully support MS Exchange right through Apple's mail and Calendar and you won't be slave to Entourage.![]()
Yes, Spaces is a known issue
Also, if you have run XSlimmer or other code strippers, the Auto Update feature has not worked
Of course the lack of VBA support in Excel has been a bone of contention as well
Woof, Woof - Dawg![]()
Unfortunately, Snow Leopard is only supporting Exchange 2007. Many of us are still running on 2003.
Snow Leopard's Mail won't support public folders? So no shared calendars, contacts or mail folders? Great, sigh...
New features but not visual basic macros for Excel, what a shame from Microsoft.
I find this hard to believe since other aspects of Office don't obey the normal interface guidelines (e.g. bringing only one window to the front instead of the whole app) and the non-MS apps seem to have no problems with Spaces.
Bear with me while I shift gears now, and talk about another issue that the MacBU has heard a lot about: Office 2008 and the OS X feature called Spaces. If you read through the links in that previous sentence, a couple of themes pop up:
Mac Office 2008 doesnt work properly with Spaces
It happens most often in Word or when the Formatting Palette is open
People rarely see the bug in non-Microsoft applications
People assume the Mac Office 2008 code base is the cause of the problem
Let me give you some of the background of the Formatting Palette, to help explain why the problem shows up so much more readily in Office 2008 than in Office 2004 or in other applications.
When people talk about the Formatting Palette in Office 2008, they usually mean the Toolbox window. The Toolbox is actually two separate windows, bound together by Carbon Window Groups. The first window has the title bar and the row of buttons across the top (the buttons that toggle between the Formatting Palette, the Scrapbook, the Reference Tools, the Object Palette, and whatever else is there that I cant remember off the top of my head.) That first window is a true floating window created by OS APIs. The second window is everything below that row of buttons, and is the instantiation of one of those toolbox items. These windows are slightly customized, in that we tell the OS to create them with no border or shadow, again through OS APIs. When the Formatting Palette is showing, youve actually got the root toolbox window showing first and then the FP window bound tightly to it, on top in the z-order. If you click on the Scrapbook button, the FP window is destroyed and a new window is created to hold the scrapbook, and that new window is bound against the root window. I think that Spaces and Exposé dont take the window bindings into account (my understanding is that they manipulate windows at the Core Graphics level, which is a lower-level private system interface upon which both Cocoa and Carbon windows sit), and that is why Spaces and Exposé seem to get confused by the root floating window and the upper child window.
The reason MacBU uses this window separation is that most of these child windows are hosted in different modules of code, most of which have their origins in different architectures. The Carbon Window Group APIs allow for very rich and precise control over how windows are presented to the user, and gave us the ability to combine UI from a variety of sources in our codebase with minimal rearchitecting of each of the individual components. The Scrapbook window, for example, is a PowerPlant window because it actually lives deep in the Entourage code (due to the fact that Entourage is currently PowerPlant-based, and that was the easiest way to get access to the Entourage database). PowerPlant is very picky about owning its entire window, which is why we use a separate window here it misbehaves rather badly if you try to put PowerPlant objects in a sub-frame of a window that is not fully under PowerPlants own control. The Formatting Palette is actually a special instantiation of the toolbar code, which has its own assumptions about the sort of window it lives in, and the Compatibilty Report is actually an instantiation of what was originally a modeless dialog.
We have long-term plans to overhaul the entire architecture of the Toolbox and all its clients to use Cocoa, but that didnt happen in 2008. The Cocoa AppKit window APIs do not yet contain functionality that supports the full richness of window management features that the Carbon APIs do. The Toolbox and its use of Carbon Window Groups were introduced in Office 2004 and predate both Spaces and Exposé. The Office 2004 Toolbox has the same issues with Spaces and Exposé, but you only notice it if you show the Toolbox. In Office 2004, the Formatting Palette was separate from the Toolbox, so the Toolbox was not shown by default. In order to reduce the amount of screen space the Toolbox and Formatting Palette obscured at the same time, we merged the two together early in the 2008 cycle, long before Leopard and Spaces were demoed or available for us to test with in beta.
After we received a beta of Leopard with Spaces, we tested our apps and identified a number of issues that our apps have with the feature. We had an engineer spend several days digging into these issues. He did some serious spelunking into our windowing code and determined that we were not moving the windows incorrectly in our code so we reported them to Apple to investigate. Apple has fixed a number of problems with Spaces in OS X 10.5.3, but some still remain.
So, lets circle this discussion back to the point I opened with, and the real point of this post: some changes are just too risky for dot-releases, and every company that writes software has to deal with that. Microsoft does and certainly Apple does too. I dont know the Spaces code as I dont work for Apple, Ive never seen it. Microsoft and Apple work together to troubleshoot customer issues as situations warrant, and as part of that joint effort Ive spent some time talking to some of the Apple Carbon and Spaces developers over the last few weeks about Spaces. We wanted to see if theres any sort of change we could make in our code to avoid the issues. If there was anything we could reasonably change in our code at this time I would love to do so. However, changing our windowing system to not use Carbon Window Groups entails a complete rewrite, and is not something we can feasibly do in a bug-fix release. Given the direction Apple is taking with OS X, any significant rewrite of our windowing system should be done in Cocoa, and that is a tremendous task to do in a dot-release. It would almost certainly cause other serious bugs as I alluded to in the charting example above. The Apple developers Ive spoken with have been unable to come up with any simple code changes to that we could make to work around the issues, and have indicated that our code is generally acting correctly.
For now, youll have to wait for Apple to release an update to or new version of OS X where Spaces works with apps that use Carbon Window Groups. Our User Experience team has put up a brief help topic about the issue. Were keenly aware of our customers frustration with Office 2008 and Spaces, and we will continue to work with Apple to help find a solution or workaround. Please continue to share your product experiences with us on Mactopia, or privately with me if you wish. As long-time software developers, its frustrating to me and to my peers when were unable to fix every problem instantly. Improving your experience with Mac Office on a continuous basis is part of our job. Sometimes we can do it with a quick fix, sometimes not. Your input helps us get it done.
Well they're not helping world hunger now are they?MR user and MS rep nadyne has repeatedly addressed this and referenced this blog as well
I cannot validate the accuracy, I'm just saying there is more to it than just bashing MS. I am no MS fan, but they are not responsible for world hunger, global warming and unrest in the Middle East
Link to Blog
Woof, Woof - Dawg![]()
I'm glad that it will supposedly run faster. If only they would add the data analysis toolkit back to excel. Oh well.
NO WORD ON MAC MESSENGER?
Their blog hasn't changed in nearly 3 months. The Mac BU is an absolute joke when it comes to mac messenger, they could atleast give us a hint as to its progress! It's the only reason why i don't like using a mac!
Meanwhile i am very glad of Sp2 i love mac office it's excellent!!
I hope so... but I doubt it. The MS Devs actually post here, and they always mention that it's one of Apple's bugs and yadda yadda yadda. I think it has something to do w/ the carbon APIs. Anyhow, I'm hoping it fixes this issue. I hate firing up any of the MS Office apps on my Mac. Slows down my whole day...Does it finally work with Spaces? Boggles the mind that 2004 worked fine with Spaces, but 2008 is all sorts of broken.
Ugh I hear ya... join the clubOnly speed updates to Word and Excel? What about Entourage? - It has got to be the slowest mail reader ever - on any platform, but I need to use it to access my company's Exchange server.![]()
Seriously? Use Adium...!