We build many office application for windows, and it work very natively with office UI but when we came to do same on office for mac we have been lost :(
We need an embedded native Microsoft word for MAC 2016 (better if works with Microsoft word for mac 2011 too)
*by native we mean to be embedded in word window, not like the VBA forms, like word panels etc
*The most important issue for us is the UI and how it will work like if it was built by Microsoft it self,
*ANY SOLUTION FOR MS-WORD FOR WINDOWS IS NOT WHAT WE ARE LOOKING FOR AT ALL, THE SCOPE IS MICROSOFT WORD BUT FOR MAC
*The UI we prefer first is something like word native pans such as
*Navigation pane
*Task pane
*Side bar/pan
if this not possible then 2nd option will be
*Ribbon
if this not possible then 3rd option will be
*Toolbox
We open to use any technology to build this, such as VBA,swift, objective-c whatever provide us with the solution we need,
Any advice??
As far as I am aware, the support for embedding native clients is going the way of the dodo. Everything is moving towards the Office Web Apps and embedding that view within applications. It might make sense to review if that allows for the functionality you are looking for based on how it's deployed.
Related
In my workplace we have several different types of systems.
Surface Pro's running Office 2016
Surface Pro's running Office 2013
Thin Clients running Office 2010
Desktops for Accessibility users running Office 2010
I develop VBA solutions that have to work across all of the above, and run into trouble with only one scenario.
I use a Surface Pro with Office 2016. If I build a document, I can run the macros I create on the Surface Pro's and Thin clients without issue, but the Desktop PC's running Office 2010 don't even get the option to turn on the macros.
If I open the file up on a desktop (seldom have access to one) and save it using that system, any other user on a desktop can open it up and the macros will work, but if anyone from one of the other systems opens it up and saves it, the desktop users will go back to square one.
At first I thought this would have been a compatibility issue relating to architecture
Can anyone think of anything before I pull the remainder of my hair out? I really want to be able to solve issues for the people having problems on desktops without having to find one myself, or worse - give them any passwords
Cheers
Go to VBA Tools and uncheck all objects marked as missing under References.
I am new to IBM Rational Functional Tester. Does anyone know if this tool supports the testing of Microsoft Office Applications? Do I need to install any special software, plugins, tools etc to get it to work?
Welcome to stackoverflow..
RFT supports applications created with .Net/WPF/Win among others and most likely MS office might be using one of them so it should work. The only problem which I anticipate is if the office uses some customized controls in those cases RFT might identify the controls as generic control. But I would try and see if how does it record on the controls (just click a few controls and look at the object map to find out what is the value of Domain property under the adminstrative Tab of the object map for one of the controls.
Better late than never,
I tried IBM Functional Test 8.6.0.5 along with Microsoft Office 2013, and the tester did not manage to work with Word. While trying to record an automated test script, none of the clicks inside word were captured.
I am looking for an interpreter (compiler would work too) for Visual Basic or VBA. I am not looking for any kind of UI support. Basically, I have a series of somewhat complex VBA modules which make no reference to any external DLLs and make no use of any user interfaces. Is there any such tool available short of having Microsoft Office or Microsoft Visual Basic for the Windows operating system?
VBA only exists as an embedded "macro language" inside a host application like Excel. At one time you could even buy the SDK to embed VBA in your own applications, but there was never any "stand alone VBA."
VBScript is close to VBA and VB in syntax and semantics, but it also requires a host. Common desktop hosts include WSH, MSHTA, and the Vista/Win7 "gadget" framework. That's probably your best bet if it meets your needs.
It is remotely possible to do what you want using VB5CCE (Control Creation Edition) if you can find it. This was free, but could not compile to EXEs. It might have worked as an interpreter however by running it with the /run switch. I'm not certain of that though.
There are 3rd party freebies as well such as Jabaco which uses a very VB/VBA-like syntax.
Update: VB5CCE does not support the /run switch.
This might be worth a peek if VB.NET is a fit. Visual Studio Express ... I'm not sure what the free version leaves out though.
http://www.microsoft.com/visualstudio/en-us/products/2010-editions/visual-basic-express
I'm looking for some advice from anyone who has experience writing addons for PowerPoint on both Windows and Mac machines.
We have a Windows Office 2007 addon (.NET) that we'd like to port to the Mac.
Thus, in PowerPoint 2008 for the Mac, we require the following functionality:
Ribbon/Fluent extensibility
Custom Task Panes
Read/write custom document properties
Save slides as images
Read text and shape information from slides
Get notification of the following PowerPoint application events; `SlideSelectionChanged`, `PresentationClose` and `AfterPresentationOpen`.
I am hoping someone with experience writing Office addons for Windows and Mac, can advise.
This doesn't solve your problem if you need to specifically do this in 2008, but Office 2011 is coming and it brings back VBA. Spending the effort to convert your stuff to AppleScript might be a lot of work for little return where you could wait for Office 2011 which brings the Ribbon to Mac Office as well as VBA...
http://www.computerworld.com/s/article/9085678/Microsoft_will_bring_back_macros_to_Mac_Office_in_2011
An application currently in development has the requirements for using MS Word to perform spell check on certain textareas within the application.
I currently have Office 2007 (which is the Office 12 com objects).
My question is, if I add in the Office 12 objects what will happen on boxes which have Office 2003? This is in regards to both other development boxes as well as the end users.
Am I correct in believing that the end result will be that the spell capabilities will not be available for those users? And if I used an Office 11 object would that mean that the users would be unable to perform the spellchecks if they have Office 07 installed?
We gave up on trying to use a dependency on Word, as both have differing versions installed or no Office installation at all! Instead opting for NetSpell.
I am guessing here, but if it is as you can't use the 2007 PIA (Primary Interop Assembly) with a 2003 installation, you could try accessing the PIA via reflection as I would guess the calls you want won't change between the two, and then it won't matter - you'll use whichever is installed. If you are installing the PIA as well, you can then either get the user to tell you which they have, or be a little more clever and just try 2007 and if it fails, try 2003.
Like I said, I'm guessing here but it might be worth a try.
EDIT: I found this link about Office PIA's. This refers to Excel but actually covers Office in general. I don't envy the task you have. Looks like you'll need to detect the PIA (which may or may not be installed) and act accordingly. Sounds like a job for reflection to me.
Newer versions of Office will maintain most if not all compatibility with older versions of COM objects. Meaning if you want to program against Office 2003 and 2007 you will need to use Office 11 COM objects as a dependency as they were the newest available when 2003 was released. As long as you verify that the methods you need exist both versions of COM objects you should have no problems as long as you use the older COM objects.
Unfortunately, although I have used this solution for my own work, I have not tested it with Spell Check. In the end make sure that you test your code with all version of Office that you wish to integrate with.
My gut reaction to this question, is to simply suggest you go another route. Try using a 3rd party spell-check control. They are relatively inexpensive (and you may find some free controls). At least that way you can control the version of the control included with your app and be able to rely on it's functionality. Quite frankly, I'm surprised this library isn't built into Windows already. Sure it's complicated with all of the languages Windows supports, but these days it's similar to copy/paste in terms of user expectations.
You can actually package both the office11 and office12 interops needed to work in BOTH versions. It takes some minor work but I managed to do it. I do a check in the registry to see which interop to call and then executes the spell checking with the correct version. It even goes so far as to check if you have Word installed and throws an error alert that you can't spell check without having Word. We're tied to using Word due to the medical dictionary that's tied into Office we're required to use.
Do a search on interop or Com wrappers and I think you'll find you can use both fairly easily.