Excel-RS232 via Cheapcomm: Where?

Or, a handheld device that needs to communicate with some sort of controller. Regardless of version upgrades in either they must still work together. An old handset must work with new controllers and vice versa. Carrying around two handsets is not an option.

Robert

For your own use, you might want to look at vmware. There is a free "server" version and a pay "workstation" version. You can setup complete "virtual machines" running dos, windows 98, whatever you like. It's very slick. The virtual machines can actually access hardware, serial ports for sure maybe parallel ports too. I actually use this on linux, but you can run it under windows too.

For the customer stuff, I guess the win32 API is the way to go - assuming you can access this from visual basic (or VBA for office programs?). There are only a couple of functions you need IIRC. I might have a look at this myself - we have some custom windows software for collecting data from serially connected equipment (using modbus). It would be neat to be able to send someone a spreadsheet and have this talk to the devices "directly". But I don't know if this is really practical, and it will probably break on vista or office 2007 etc.

They dont restrict it. If you package it up using VB, then you can distribute it freely. IF you have any questions about distributing it as part of excell then send an email to MS legal, they will give you the answer.

What you are doing is outside the realms of what Excel was designed to do, why dont you just obtain a second hand copy of VB and use that? You can then package up the ocx and install it on any pc you want.

Office 2007 uses the same technology (VBA) but i just had a look and i cant see the com control object. It may still be shipped with office but its not immediately visible.

Yes, but back in the DOS days there was no braodband, and there was no fancy monitors and digital cameras. there was no CD's (maybe just) and no MP3's. There was no portable music players and skype. There was text based word processors and dot matrix printers. Monochrome screens (4 colours if you were lucky) and speakers that beep instead of playing music.

Now tell me functionality has not increased.

Was the same in '97. They do not allow the use of mscomm unless you also buy a VB Pro license. At least that's how I understood it. Makes absolutely no business sense on the part of Microsoft but then again a lot of things don't make sense.

Thanks, I forgot about that.

Yes, exactly, it'll be customer stuff so has to run on whatever their IT guys have blessed. And that will be the usual Windows/Office setup. Sometimes MS thoroughly messes up, like with .NET or Vista, but with Office they have (so far, knock on wood ...) not wrecked backward compatibility. If they did the repercussions from the business community would be severe. There is a lot more legacy stuff in business that remains crucial and will be used for years to come. Many of their financial files and routines date all the way back to the 80's.

AFAIU you need to have a VB copy on each PC it gets installed on. Sure, you can then remove it but that scrapes the fringes of the legit range. Also, IT folks dislike installing programs that don't come from major SW design houses. With an Excel file that's different even if they have to click ok for macros because it is still considered a file. Although a heavily VBA-laden file is in reality software.

Yes. What were they thinking? In order to remain compatible it seems you must install the old versions along with the latest. Man, the FDA would rip me apart in the air if I ever designed something like that.

Hey, I had a Freecom CD box, 16 colors, and a well functioning HP DeskJet. Later a HPII LaserJet. Web sites were not fluffified but practical. Case in point: Sabre. Since I flew an enormous amount of miles some airlines allowed me to call my flights in directly. Sabre was strictly ASCII based, meaning blazingly fast over the 7-8K my modem could realistically yield. Then Sabre was bought up and it was all over, it suffocated in new fluff :-(

For engineers who design electronic circuits it hasn't increased too much. Ok, there is a whole lot more content on the web now versus back then. But when I look at my design process I see this:

DOS:

The OS is nearly unconditionally stable and blazingly fast. Laptops ran

OrCad 3.22 (MUCH better than today's) MS-Word 5.0 (imported schematics and graphics just fine) MS-Works 2.0 (did all the biz books) Mosaic browser (the best I ever had, never crashed, not once) CompuServe email client (also the best, did _not_ do single file) MS C-Compiler 7.0 (if I wanted to be dangerous...)

Windows today:

OS is totally sluggish, need two PCs at any given time to reach same productivity as with DOS. Laptops slurp up the charge of an expensive LiIon battery in under 2hrs, a large percentage of which is wasted in Windows overhead activity. Crashes galore.

Eagle (OrCad costs 3x of the DOS version, crashes too much IME) MS-Word 2000 (Ok, but does crash once in a while) MS-Works for Windows (Ok, but slow, too much fluff) Mozilla (Crashes much less than IE but bloated) Thunderbird (Ok, but also a bit largish) IAR Suite because I went to uC (Pretty nice, actually)

So, there.

Look at how often the word crash occurs in each category. I know that the picture changes for someone like a marketing pro or graphics artist but for a HW designer the main difference is that both reliability and speed took a dump.

You know, I'm not the world's most fervent Microsoft admirer by a long shot, but I would find it hard to describe them as anything other than a "major SW design house".

-=Eric

It wasn't about them. It was about me (or rather someone more versed in programming) writing VB Code. That would be a not so major SW design house ;-)

Let me guess - you design devices which have one, or maybe two, interfaces, being mostly in simple master-slave relationships?

Now try considering a system of 30,000-50,000 separate components, each one with a dependency on from 5 to 50 of the others, each one potentially with flaws and outstanding change requests, and you get some concept of the configuration complexity. We're talking hundreds of millions of times more configuration risk (in terms of ramifications of a change in any one of those interfaces) than you have in your devices.

I'm not saying your devices aren't more complex internally, or that each interface isn't complex in itself, and it's probable that *that* complexity is higher than each of the elements of a generalized software runtime, but they still aren't even on the same planet when you consider configuration risk.

It doesn't help that the Windows APIs are at least an order of magnitude more numerous than strictly required... but that's exactly why the .NET runtime was necessary... it forms a new platform that's vastly simpler than the old one, and can move off Intel architectures to boot (vis Mono).

Clifford Heath.

They are a bit more complicated than that but not five-digit. The largest ones I design typically still have less than 100 locations that need to exchange data. But some of those are realtime to the point where, for example, another section of the whole system needs to trigger on an ECG signal within spec'd accuracy. Failure to do so in timely fashion can cause some grief.

I don't dispute the need for something like .NET. It's just that I find the implementation not to be as organized as I'd like it or as agencies may request that our systems live up to.