PDA

View Full Version : XL file with both Mac & PC users: plugin possible?



Blakieto
08-02-2004, 05:52 PM
I have a set of managers that are using Excel to schedule their staff. I created a plugin that contained the complex logic and got the 13 different workbooks(departments) all operating off copies of a template workbook, filled with their staff. Then I have a company summary workbook that consolidates all these different departments people and their schedules. All fine and dandy...

However, 4 of our department managers are Mac users...

I tried earlier to simply load the plugin.xla file on one of the Macs... that simply crashed.

Then I tried to take the source VBA code of the plugin and compile that on one of the Macs... that's where I discovered Split() and symbols for FormatDateTime() to be missing...

Once I got Mac replacements to the above and the plugin to compile... I find that the various cell references to the plugin functions contain the complete path to the plugin! (Which is the path within the PC that the workbook was originally created.) Accessing the "Links..." dialog sends me into an endless loop of "okays" to Excel's inability to find the function names that exist inside the plugin, but not with the explicit path names from the PC.

The only way I've been able to get these workbooks to function is to do away with the plugin entirely, and place copies of the VBA macro logic inside a code module for each workbook's. Ugly duplication of logic, and a maintenance headache.

Am I missing something here? Are plugins that operate on both the Mac and PC not possible? What is with the complete path to each plugin function being bound to each function reference? This breaks the entire workbook if the plugin changes location...

Any recommendations out there?
-Blakieto

shades
09-15-2004, 01:07 PM
Am I missing something here? Are plugins that operate on both the Mac and PC not possible? What is with the complete path to each plugin function being bound to each function reference? This breaks the entire workbook if the plugin changes location...

Any recommendations out there?
-Blakieto
Many xla plug-ins are not cross-platform. Occasionally you will find one. The Named Range manager (www.decisionmodels.com ) is one that has been modified to work in both environments.

As far as the path, Macs use a different path method for reaching the file. I can provide more later tonight.

Are these Macs OS X? Are they using Excel v. X or Excel 2004?

Blakieto
09-15-2004, 01:19 PM
These Macs are OS X and they are running the latest version of Excel for OS X, which ever that is. We just completed the upgrade not to long ago- few weeks ago.

-Blakiteo

shades
09-15-2004, 01:20 PM
Okay, that means OS X 10.3.5 Panther, and if Excel is latest, then Excel 2004. That is what I have on my system at home. It will be about 6 hours before I can make sure on the path language.

(I leave work in a little while, then have to teach for a while.)

shades
09-16-2004, 09:09 AM
Here is a link where I placed the path adjustments.


http://www.vbaexpress.com/forum/showthread.php?t=565

Howard Kaikow
10-03-2004, 11:48 PM
I have a set of managers that are using Excel to schedule their staff. I created a plugin that contained the complex logic and got the 13 different workbooks(departments) all operating off copies of a template workbook, filled with their staff. Then I have a company summary workbook that consolidates all these different departments people and their schedules. All fine and dandy...

However, 4 of our department managers are Mac users...

I tried earlier to simply load the plugin.xla file on one of the Macs... that simply crashed.

Then I tried to take the source VBA code of the plugin and compile that on one of the Macs... that's where I discovered Split() and symbols for FormatDateTime() to be missing...

Once I got Mac replacements to the above and the plugin to compile... I find that the various cell references to the plugin functions contain the complete path to the plugin! (Which is the path within the PC that the workbook was originally created.) Accessing the "Links..." dialog sends me into an endless loop of "okays" to Excel's inability to find the function names that exist inside the plugin, but not with the explicit path names from the PC.

The only way I've been able to get these workbooks to function is to do away with the plugin entirely, and place copies of the VBA macro logic inside a code module for each workbook's. Ugly duplication of logic, and a maintenance headache.

Am I missing something here? Are plugins that operate on both the Mac and PC not possible? What is with the complete path to each plugin function being bound to each function reference? This breaks the entire workbook if the plugin changes location...

Any recommendations out there?
-Blakieto
The only way to have 100% Mac/Win Office VBA compatibility is to restrict your coding on the Windoze side to VBA 5, i.e., Office 97, no higher.

You can come up with alternatives for functions such as Split, Join, etc, but you cannot come up with alternatives for object model differences and capabilities such as modeless Userforms.

Howard Kaikow
10-03-2004, 11:53 PM
Here is a link where I placed the path adjustments.


http://www.vbaexpress.com/forum/showthread.php?t=565
For path compatibility, you'll haver to use code that:

1. Conditionally executes based on whether it is Mac or Windoze Office.
2. Use the Application.PathSeparator property, instead of hardcoding the critters.
3. Localize hard path references and represent them as document or windows objects in the guts of the code.

Howard Kaikow
10-03-2004, 11:55 PM
And to make matters worse, what is going to happen to Mac/Win Office compatibility when Win Office is fully .Net-ized?


Will VB .NET, etc. be ported to the Mac?
In what time frame?

shades
10-04-2004, 11:00 AM
And to make matters worse, what is going to happen to Mac/Win Office compatibility when Win Office is fully .Net-ized?


Will VB .NET, etc. be ported to the Mac?
In what time frame?
I agree this will be an end to "cross-platform" capability. I suspect that VB .NET will never be ported to Macs, just like Access will never be ported. It allows MS to maintain control of the corporate environment.

I'm not into programming at all, so have no idea what would be a comparable language on the Mac side to VB .NET.

Howard Kaikow
10-04-2004, 12:15 PM
I agree this will be an end to "cross-platform" capability. I suspect that VB .NET will never be ported to Macs, just like Access will never be ported. It allows MS to maintain control of the corporate environment.

I'm not into programming at all, so have no idea what would be a comparable language on the Mac side to VB .NET.
It's not a matter of what the Mac has that's comparable to VB .NET, the key is the integration of VB .NET and C# into Office.

shades
10-04-2004, 02:00 PM
Okay, thanks. Like I say I am a neophyte in understanding all this.