Excel-RS232 via Cheapcomm: Where?
in [Embedded]
|
Prev: About NXP TDA8007 (smart-card chip controller)
Next: GNUARM multiple definition of AT91F_AIC_ConfigureIt
From: Robert Adsett on 26 Sep 2007 23:10 In article <%QCKi.29677$eY.9501(a)newssvr13.news.prodigy.net>, Joerg says... > Clifford Heath wrote: > > You should be congratulating MS for finally doing something positive about > > solving DLL hell, not castigating them for your mistake. > > > > Your are probably right. However, that's a "version control" scheme that > is totally foreign to me. And I bet in my line of biz (FDA regulated) > the Federales wouldn't let that fly. With our SW newer versions must > support the old stuff. Just imagine the ER doc loading a patient file > because he urgently needs to get some info, then a message pops up > "Requires DICOM version x.xx, please contact your IT administrator". 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 -- Posted via a free Usenet account from http://www.teranews.com
From: John Devereux on 27 Sep 2007 05:05 Joerg <notthisjoergsch(a)removethispacbell.net> writes: > Clifford Heath wrote: > >> Joerg wrote: >> >>> 40MB to get to the ports, wow ... >> >> >> Getting to the ports might be all *you* wanted, but the runtime provides >> an entire JIT compiler-interpreter and its runtime library, i.e. it's an >> entire platform, and actually quite small for what it is. >> > > I just don't understand why Billy's folks restricted mscomm.ocx. It > prevents tons of Excel and Office sales into labs from happening. From > a revenue POV that is like shooting themselves in the foot. > > >>> Your are probably right. However, that's a "version control" scheme >>> that is totally foreign to me. >> >> >> So you'd expect that old DOS program to still work under Vista, would you? > > > Honestly I do not care because I won't let Vista into the business > here. I did run some in XP. Actually I have to because some of the old > filter design routines don't come any other way. The usual, a prof had > an excellent group that wrote all this. Then he got older, retired, > new prof came in, had other priorities on his mind and the project > withered away. > > If XP wouldn't have run it I would just downgrade to Win2K. The only > price a biz user really pays is that some stuff might then only be > driveable in plain vanilla modes. 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. -- John Devereux
From: The Real Andy on 27 Sep 2007 06:37 On Thu, 27 Sep 2007 01:14:58 GMT, Joerg <notthisjoergsch(a)removethispacbell.net> wrote: >Clifford Heath wrote: > >> Joerg wrote: >> >>> 40MB to get to the ports, wow ... >> >> >> Getting to the ports might be all *you* wanted, but the runtime provides >> an entire JIT compiler-interpreter and its runtime library, i.e. it's an >> entire platform, and actually quite small for what it is. >> > >I just don't understand why Billy's folks restricted mscomm.ocx. It >prevents tons of Excel and Office sales into labs from happening. From a >revenue POV that is like shooting themselves in the foot. > 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. > >>> Your are probably right. However, that's a "version control" scheme >>> that is totally foreign to me. >> >> >> So you'd expect that old DOS program to still work under Vista, would you? > > >Honestly I do not care because I won't let Vista into the business here. >I did run some in XP. Actually I have to because some of the old filter >design routines don't come any other way. The usual, a prof had an >excellent group that wrote all this. Then he got older, retired, new >prof came in, had other priorities on his mind and the project withered >away. > >If XP wouldn't have run it I would just downgrade to Win2K. The only >price a biz user really pays is that some stuff might then only be >driveable in plain vanilla modes. > > >> Myself, I'd rather that the platform moves on occasionally, and that means >> breaking compatibility with programs that depend on bugs and design flaws >> in the old version. At least with .NET you have the option of running old >> programs on the old runtime, and new ones with the new one. It's not as >> though they've released hundreds of versions, after all - there are only >> two in play currently and a third coming. >> > >In the med biz we don't like such moves. Our liability insurers don't >either ;-)
From: The Real Andy on 27 Sep 2007 06:43 On Thu, 27 Sep 2007 10:05:01 +0100, John Devereux <jdREMOVE(a)THISdevereux.me.uk> wrote: >Joerg <notthisjoergsch(a)removethispacbell.net> writes: > >> Clifford Heath wrote: >> >>> Joerg wrote: >>> >>>> 40MB to get to the ports, wow ... >>> >>> >>> Getting to the ports might be all *you* wanted, but the runtime provides >>> an entire JIT compiler-interpreter and its runtime library, i.e. it's an >>> entire platform, and actually quite small for what it is. >>> >> >> I just don't understand why Billy's folks restricted mscomm.ocx. It >> prevents tons of Excel and Office sales into labs from happening. From >> a revenue POV that is like shooting themselves in the foot. >> >> >>>> Your are probably right. However, that's a "version control" scheme >>>> that is totally foreign to me. >>> >>> >>> So you'd expect that old DOS program to still work under Vista, would you? >> >> >> Honestly I do not care because I won't let Vista into the business >> here. I did run some in XP. Actually I have to because some of the old >> filter design routines don't come any other way. The usual, a prof had >> an excellent group that wrote all this. Then he got older, retired, >> new prof came in, had other priorities on his mind and the project >> withered away. >> >> If XP wouldn't have run it I would just downgrade to Win2K. The only >> price a biz user really pays is that some stuff might then only be >> driveable in plain vanilla modes. > >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. 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.
From: The Real Andy on 27 Sep 2007 07:02
On Thu, 27 Sep 2007 00:48:17 GMT, Joerg <notthisjoergsch(a)removethispacbell.net> wrote: >Robert Adsett wrote: > >> In article <LovKi.9066$JD.147(a)newssvr21.news.prodigy.net>, Joerg says... >> >>>I am not a fan of .NET. It seems to have serious backwards compatibility >>>issues. Case in point: New scope SW came, must have .NET. Installed 2.0, >>>did not work. Inquired -> Must use 1.1 because 2.0 is not compatible. >>>Great. <shaking head> >> >> >> That appears to be Microsofts latest approach to solving version >> dependancy issues. Just run a separate copy of every version. So if >> you have a program using version 1 and another program using version 2 >> you get both copies in memory. >> >> It appears they've given up on the idea of actually getting it right. I >> don't know if it's a reasoable approach but it sure rubs the wrong way. >> > >ROFL! That was a good one. But it sure looks like it. Now if it was only >.NET that would be one thing. The world would keep spinning without it. > However, it seems there is now an "oh s..t" experience even with Vista. > >Anyhow, I have become very careful WRT adopting all this newfangled >stuff from up there. Ordered a new desktop today. With XP. Surprisingly >the sales guy at the small biz desk told me right off the bat before I >had even brought it up "And you want XP on there, right?" > >It's not that I am dissing MS for everything. They did produce some nice >and useful SW packages. Office being one of them, but also MS-Works. > > >> Just in case you were wondering why disk and memory requirements keep >> climbing w/o bound. >> > >Bloat without bounds. Funtionality doesn't grow in proportion though. >This whole problem with RS232 into spreadsheet was a non-issue in the >DOS days. I used MS-Works. It had a built-in terminal program that could >pipe in the data, a spreadsheet, a word processor and a database. So >when I wanted to recreate and decode a datastream out of my logic >analyzer (to diagnose ADC distortion effects) I grabbed a serial cable, >plugged it in, and bingo. No .NET, no Active-X, no DLL hassles. It >simply worked. 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. >Heck, if I have my druthers one day I may just go back to that MS-Works >program. It's still here, on a 5-1/4 floppy. I wonder if the COM ports >can be addressed from a DOS window. |