cross-platform: Visual Basic

On 10/6/06 11:53 AM, "Lawrence Kirkendall" <lawrence.kirkendallbio.uib.no>
wrote:

> Hi,I work with insect taxonomy. I have a colleague using Windows who has a
> simple (but large) database in Excel which he has built up over many years,
> which he tells me incoporates Visual Basic modules. These modules don't work
> on his wife's Mac. Anything we can do about this? I have a new iMac and will
> be installing Parallels soon, but hope to be able to continue working with the
> Mac versions of Office software, since I have been using them literally since
> version 1 (anyone out there remember File? I thought it a pity that MS stopped
> developing that for Macs...)

The latest news from Microsoft about Mac Office is that the next version
(which will run native on Intel Macs) will drop support for Visual Basic for
Applications entirely. As you have already discovered, Mac Visual Basic has
never quite been the equal of Windows Visual Basic. So I'd say there is no
hope of getting your Windows-built macros to run on an Intel Mac. For an
explanation of why Microsoft is dropping VBA for the Mac, read here:

<http://db.tidbits.com/article/8637 >

--
Allen Watson . Writer/Webmaster [ p. 503 .281 .0250 m. 503 .916 .9411
e. watson.allencomcast.net
homepage.mac.com/allen_a_watson/

At 2006-10-06 11:53 -0700 Lawrence Kirkendall wrote:

>I have a colleague using Windows who has a simple (but large)
>database in Excel

Larry - show your friend FileMaker Pro running cross-platform and try
to cushion his disappointment at the time he's wasted writing visual
basic stuff :-)

Seriously, it should be simple to convert the Excel file to FMP and
replicate the visual basic stuff with scripts. (If you want to pursue
this and would like assistance, contact me off-list.) As your friend
has proved, using a spreadsheet for database management is possible,
but the productivity and capabilities are much improved when you use
the right tool for the job.

The fact that he has not chosen to develop using MS's Access database
manager is probably a reflection of the user-friendliness of that
package ....

>anyone out there remember File? I thought it a pity that MS stopped
>developing that for Macs

No, I never used that; but I wonder if when Claris dropped their very
nice spreadsheet Resolve and gave the market to MS Excel, perhaps MS
decided Claris could have the user-friendly database manager market
with FMP?

regards

Rowland
--
| Wilma & Rowland Carson http://home.clara.net/rowil/
| <rowilclara.net> ... that's Rowland with a 'w' ...

> I have a colleague using Windows who has a simple (but large) database in
> Excel which he has built up over many years, which he tells me incoporates
> Visual Basic modules. These modules don't work on his wife's Mac. Anything
> we can do about this?

Cross-platform scripting - that's non-trivial... :-/

You may try out Openoffice (Neooffice on the Mac), but I dhave no clue how
compatible their Basic dialect is with MS VB. Cross-platform portability is
one of the reasons why I'm using Python for scripting on both MacOS and
Windows.

Apart from that, I would use an actual database for database applications and
use the spreadsheet only as front-end. :->

Sincerely,

Wolfgang Keller

--
My email-address is correct.
Do NOT remove ".nospam" to reply.

So when you say they don't work, what happens exactly? Are you getting an error message or just not the expected result?

We do a lot of cross-platform work with Visual Basic and it (mostly) works, although there are some things you can do on either the Mac or PC side that won't work on the other platform.

On 10/10/2006 9:31 AM, "Rowland Carson" <rowilclara.net> spake thus:

> No, I never used that; but I wonder if when Claris dropped their very
> nice spreadsheet Resolve and gave the market to MS Excel, perhaps MS
> decided Claris could have the user-friendly database manager market
> with FMP?

That puts me in mind of the Catholic Church dividing the world up between
the Spanish and the Portuguese back in the 16th (?) century or thereabouts.
Does that make Bill Gates the Pope?

;)

--
Nigel Stanger, Dunedin, NEW ZEALAND.
http://xri.net/=nigel.stanger

On 10/9/06 15:31, "Wolfgang Keller" <wolfgang.keller.nospamgmx.de> wrote:

>> I have a colleague using Windows who has a simple (but large) database in
>> Excel which he has built up over many years, which he tells me incoporates
>> Visual Basic modules. These modules don't work on his wife's Mac. Anything
>> we can do about this?
>
> Cross-platform scripting - that's non-trivial... :-/
>
> You may try out Openoffice (Neooffice on the Mac), but I dhave no clue how
> compatible their Basic dialect is with MS VB. Cross-platform portability is
> one of the reasons why I'm using Python for scripting on both MacOS and
> Windows.

I'm guessing you're doing this in a very controlled environment, as
otherwise, you've no chance of running python on stock windows

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com

>> Cross-platform scripting - that's non-trivial... :-/
>>
>> You may try out Openoffice (Neooffice on the Mac), but I dhave no clue how
>> compatible their Basic dialect is with MS VB. Cross-platform portability is
>> one of the reasons why I'm using Python for scripting on both MacOS and
>> Windows.
>
> I'm guessing you're doing this in a very controlled environment, as
> otherwise, you've no chance of running python on stock windows

Don't know where you've got that rumor from, but it's total nonsense.

I've never had any kind of problems whatsoever to install and work with
Python on Windows.

Sincerely,

Wolfgang Keller

--
My email-address is correct.
Do NOT remove ".nospam" to reply.

On Oct 11, 2006, at 4:39 AM, Wolfgang Keller wrote:

>>> Cross-platform scripting - that's non-trivial... :-/
>>>
>>> You may try out Openoffice (Neooffice on the Mac), but I dhave no
>>> clue how
>>> compatible their Basic dialect is with MS VB. Cross-platform
>>> portability is
>>> one of the reasons why I'm using Python for scripting on both
>>> MacOS and
>>> Windows.
>>
>> I'm guessing you're doing this in a very controlled environment, as
>> otherwise, you've no chance of running python on stock windows
>
> Don't know where you've got that rumor from, but it's total nonsense.
>
> I've never had any kind of problems whatsoever to install and work
> with
> Python on Windows.

Oh come on. Note the operative word in your sentence: "install"

Unless things have changed radically -- I just checked, and they
haven't -- Windows doesn't ship with the standard scripting languages
that other platforms come with -- Python, Perl, Ruby, Bourne, etc.

They run well enough if you install them, as you say.

But if you're trying to manage a bunch of computers, then you have to
arrange for the software to be installed on all of them, as he said.

But maybe you're just being difficult for the fun of it :-)


--
Chris Devers

On 10/11/06 03:39, "Wolfgang Keller" <wolfgang.keller.nospamgmx.de> wrote:

>>> Cross-platform scripting - that's non-trivial... :-/
>>>
>>> You may try out Openoffice (Neooffice on the Mac), but I dhave no clue how
>>> compatible their Basic dialect is with MS VB. Cross-platform portability is
>>> one of the reasons why I'm using Python for scripting on both MacOS and
>>> Windows.
>>
>> I'm guessing you're doing this in a very controlled environment, as
>> otherwise, you've no chance of running python on stock windows
>
> Don't know where you've got that rumor from, but it's total nonsense.
>
> I've never had any kind of problems whatsoever to install and work with
> Python on Windows.

You do realize that "installing Python on windows" means that you aren't
working with *stock* windows. That would be where that "stock windows" bit
is important. Windows doesn't *ship* with python.


As well, in a large scale setup, that also means you have to have the plans
in place to deal with patches and updates in an organized fashion. When
you're talking about 10-20 systems, not a big deal. When you're talking
about 800 or more systems? It's a bit more of an issue.

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com

On Oct 11, 2006, at 12:54 PM, John C. Welch wrote:

> As well, in a large scale setup, that also means you have to have
> the plans
> in place to deal with patches and updates in an organized fashion.
> When
> you're talking about 10-20 systems, not a big deal. When you're
> talking
> about 800 or more systems? It's a bit more of an issue.

Interestingly, there is a Python patch now emerging (buffer overflow
in repr() ). I don't know how the patch will get into Windows
installs of Python (perhaps a fresh full install?).

   --John

--On October 11, 2006 12:54:20 PM -0700 Chris Devers <cdeverspobox.com>
wrote:
> Oh come on. Note the operative word in your sentence: "install"
>
> Unless things have changed radically -- I just checked, and they
> haven't -- Windows doesn't ship with the standard scripting languages
> that other platforms come with -- Python, Perl, Ruby, Bourne, etc.

It also doesn't ship with either Visual Basic or Visual Basic for
Applications. You have to install either the Express version of VB or
Microsoft Office (there is also a standalone installer for VBA).

The only scripting languages stock Windows ships with is VBScript
(different than VB or VBA), JavaScript and batch files.

If you want to use .Net that is also an install for XP and 2000. If you
want .Net 1.0 or 2.0 it's an install on all their platforms.

On 10/12/06 01:46, "Kevin van Haaren" <kevinvanhaaren.net> wrote:

> If you want to use .Net that is also an install for XP and 2000. If you
> want .Net 1.0 or 2.0 it's an install on all their platforms.

However, that's an install pushed out by Microsoft via Windows/Microsoft
update, and easily handled from a WSUS server. Things like Python and Ruby
aren't

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com

On 10/12/06 11:41 AM, "John C. Welch" <jwelchbynkii.com> wrote:

> On 10/12/06 01:46, "Kevin van Haaren" <kevinvanhaaren.net> wrote:
>
>> If you want to use .Net that is also an install for XP and 2000. If you
>> want .Net 1.0 or 2.0 it's an install on all their platforms.
>
> However, that's an install pushed out by Microsoft via Windows/Microsoft
> update, and easily handled from a WSUS server. Things like Python and Ruby
> aren't

Any shop running WSUS for deploying Windows and Office updates should be on
the ball enough to be able to distribute software packages by Active
Directory group policy. ActivePython, the Python distribution from
ActiveState is helpfully provided as an MSI file, the preferred format for
group policy software deployments. I don't think the fact that OS X bundles
a slew of scripting languages is a mark of superiority.

To try to bring this back to the Mac realm, how would one do a mass
deployment of a scripting language to OS X clients? Would ARD be a practical
choice?

On 10/13/06 14:56, "Curtis Wilcox" <tidbitscognize.org> wrote:

>>> If you want to use .Net that is also an install for XP and 2000. If you
>>> want .Net 1.0 or 2.0 it's an install on all their platforms.
>>
>> However, that's an install pushed out by Microsoft via Windows/Microsoft
>> update, and easily handled from a WSUS server. Things like Python and Ruby
>> aren't
>
> Any shop running WSUS for deploying Windows and Office updates should be on
> the ball enough to be able to distribute software packages by Active
> Directory group policy. ActivePython, the Python distribution from
> ActiveState is helpfully provided as an MSI file, the preferred format for
> group policy software deployments. I don't think the fact that OS X bundles
> a slew of scripting languages is a mark of superiority.

That only works for the initial install, and MSIs are not foolproof by a
long shot. It doesn't handle things like updates and the like, which add
manual steps into a fairly automatic process.

It's not a case of superiority either. It's a case of realizng that Python
is not going to work on Windows without some work on IT's part.

>
> To try to bring this back to the Mac realm, how would one do a mass
> deployment of a scripting language to OS X clients? Would ARD be a practical
> choice?

Apple Remote Desktop would be the best choice, with the caveat that all the
issues that exist with installing scripting languages on Windows apply to
Mac OS X as well. Having said that, there's not a lot of scripting languages
that require a manual install for OS X.

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com

On Oct 13, 2006, at 3:56 PM, Curtis Wilcox wrote:

> [...] I don't think the fact that OS X bundles
> a slew of scripting languages is a mark of superiority.
>
> To try to bring this back to the Mac realm, how would one do a mass
> deployment of a scripting language to OS X clients? Would ARD be a
> practical choice?

Well, sure, but hang on, think that through: what would you install?
Out of the box, you get, among others:

* Perl
* Python
* Ruby
* Java
* Tcl
* PHP
* Bourne / tcsh / ksh / etc
* A big suite of general utilities (grep / sed / awk / etc)
* lex/flex & yacc/bison (okay I'm just getting silly there)
* osascript / Applescript (hey, not so silly all of a sudden!)

Plus, install XCode and you get gcc (C / C++ / ObjC / Fortran / ...).

In other words, what major language, aside from the VB-derived
family (that really only runs well on Windows to begin with) is
not on that list?

The point isn't to find a way to show that Macs need a way to
distribute better tools, because the built-in toolkit is pretty
darn good out of the box.

The point is that, with that pretty darn good toolkit, you
shouldn't need more *tools*, so you're free to focus on
distributing better *solutions*. Better still, you can pick ones
that mix & match tools -- an Applescript that calls out to Perl,
or a Python script that makes an osascript call -- to make your
solutions as simple and effective as possible for both you as the
developer as well as the user on the other end.

IMO, that slew of scripting languages is absolutely superior to
a platform where you have to start by building foundations first.


--
Chris Devers

On Oct 14, 2006, at 5:28 PM, Chris Devers wrote:
> Out of the box, you get, among others:
>
> * Perl
> * Python
> * Ruby
> * Java
> * Tcl
> * PHP
> * Bourne / tcsh / ksh / etc
> * A big suite of general utilities (grep / sed / awk / etc)

> * lex/flex & yacc/bison (okay I'm just getting silly there)

Some of us seriously use these two tools still. (flex is the open
source version of lex, and bison is the open source version of yacc,
for those who may not know.) At least I did at my last job, though
that was on Linux and SunOS, not MacOS. They still do their jobs
quite well. Of course they aren't properly scripting languages.
They are languages which are compiled into C or C++, which in turn
must be compiled, assembled, and linked to yield an executable
program. The original Unix programs, lex and yacc, don't work for C+
+, at least not without great contortions (or at least they didn't in
the last versions I knew under a commercial version of Unix), and
there are other extensions and slight changes in the GNU copies, flex
and bison, which we have with MacOS.

These two languages were written primarily for writing language
compilers. flex is a language for writing lexical analyzers. It's
primary intended use is for identifying the low-level keywords,
symbols, and names in a language, though for simple files it can be
used to parse the entire structure of the file. When used with yacc
(which stands for Yet Another Compiler Compiler), or its alter-ego
bison, will return a token for each keyword, symbol, or name it
finds, so that bison can parse the structure of the file and do any
code generation necessary.

OK, so these aren't things most Macintosh users want to know about.
Maybe I'm silly responding to that comment. :^) But it's remotely
possible that this information will be slightly interesting to
*somebody*.

On 12/10/2006, at 8:54 AM, John C. Welch wrote:

> You do realize that "installing Python on windows" means that you
> aren't
> working with *stock* windows. That would be where that "stock
> windows" bit
> is important. Windows doesn't *ship* with python.

You don't need to install all of Python to use it to script Office -
simply use py2exe to create standalone utilities. I have plenty of
Windows applications (some standalone, some Office plug-ins) that
clients use on machines without a standalone Python install that use
Python & COM to automate Office in some way.

Sure, you have to install the application/plug-in, but you have to
get the VBA script, too, so there really isn't any difference there.

However, although Python is cross-platform, I'm not sure how simple
it would be to control Office (or any other Microsoft product) with
it in a cross-platform way (for other tasks, of course, it's
perfect). On Windows, you use COM, but on OS X, I presume you use
Applescript (from Python). So there has to be a layer that provides
the cross-platform code - if the script isn't doing anything complex,
it might be simpler to just write separate scripts (in which case,
they could just be in different languages, e.g. VBA & Applescript).

On the other hand, it wouldn't be all that much work to write a
Python module that did provide this functionality. All it would have
to do is wrap COM where sys.platform=="win32" and wrap Applescript
where sys.platform=="darwin" (assuming that the intersection of COM &
Applescript functionality covers the majority of the individual
functionality). If there's demand, I'm sure such a module will be
created and released.

=Tony.Meyer

On 10/23/06 04:34, "Tony Meyer" <ta-meyerihug.co.nz> wrote:

>> aren't
>> working with *stock* windows. That would be where that "stock
>> windows" bit
>> is important. Windows doesn't *ship* with python.
>
> You don't need to install all of Python to use it to script Office -
> simply use py2exe to create standalone utilities. I have plenty of
> Windows applications (some standalone, some Office plug-ins) that
> clients use on machines without a standalone Python install that use
> Python & COM to automate Office in some way.

And of course, you can embed this in with Office documents, so they "just
work"?

>
> Sure, you have to install the application/plug-in, but you have to
> get the VBA script, too, so there really isn't any difference there.

Well, yes, yes there is. Since VBA ships with Office, it's already there.
You don't need to install third party components, deal with third party
compatibility issues, and figure out "some way" to make third party stuff
work.

Python is not, as of yet, a solution here.

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com

On Oct 23, 2006, at 1:56 PM, John C. Welch wrote:

> Well, yes, yes there is. Since VBA ships with Office, it's already
> there.

It ships with Office now. It won't ship with Office 2007 for Mac,
and seemingly won't be part of Office 13 (or perhaps 14) on the
Windows side either. (I think my source for the Windows assertion
was the MacBU blog, but I'm not sure.)

   --John

On 10/24/06 14:42, "johnbaxterlistsmac.com" <johnbaxterlistsmac.com>
wrote:

>> Well, yes, yes there is. Since VBA ships with Office, it's already
>> there.
>
> It ships with Office now. It won't ship with Office 2007 for Mac,
> and seemingly won't be part of Office 13 (or perhaps 14) on the
> Windows side either. (I think my source for the Windows assertion
> was the MacBU blog, but I'm not sure.)

Well, *now* is what we're talking about. Office 12 on the Mac isn't shipping
until late summer-ish 2007. That's a ways off. The next windows version is,
at best, more than a year away, since 2007 isn't releasing until 2007
anyway.

As well, we don't know what the final answer to the VB issue on the Mac side
will be. ALL we know is, it won't be VBA.

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com