jwcolby
jwcolby at colbyconsulting.com
Fri Sep 10 07:34:20 CDT 2010
Gustav, That does sound amazing, and I will check it out. I am all about C# / Visual Studio. However understand that this is an existing (very old) fairly large application, written ages ago in Access (by a developer long gone), that I simply maintain for my client. This specific piece is taking data from this system, pulling the billing information into a form and trying to allow them to get the data out of Access and into the Web page in an expeditious fashion. Not a trivial task (at least in Access) given the web form I have to work with. I might be able to convince them to move just this one piece out to an external application. This is a huge time suck for them and the rest of the state of PA. To be honest I am praying that they will wise up and start accepting data files. Anyway, thanks for continuing to mention LightSwitch. I will definitely check it out. Are you using it for anything specific yet? John W. Colby www.ColbyConsulting.com On 9/10/2010 8:15 AM, Gustav Brock wrote: > Hi John (et al) > > It's about time you spend some hours with the beta of LightSwitch, the new rapid development "shell" to Visual Studio 2010: > > http://www.microsoft.com/visualstudio/en-us/lightswitch > > and watch the tutorial videos. It is an amazing piece of software - kind of what Access could have been, had the Access team primarily had the developer in mind. > > The way controls of screens (= forms) are organized is so clever that you wonder why no one has figured this out before. Note too how you can change "skin" from a normal desktop app to a highly optimized touch-screen app, and how - by flipping a switch - you change the resulting app from a desktop app to a web app. And everything behind the scene you can customize and expand in C# or VB.NET. > > /gustav > > >>>> jwcolby at colbyconsulting.com 10-09-2010 13:32>>> > Yes, but I need the program to do stuff in access. While I can appreciate using scripting > languages, there is something to be said for using the language built in to Access. > > The user enters sets of data records, basically all services supplied to a specific child by a > specific therapist during a week. After entering the last record for that child, the user clicks a > button on the web page and the web page returns a "status" for all of the records entered, which I > then have the user capture and insert back into a control on the form and more code runs in the form > to parse that information and writes back into all of the records entered for that child. > > It is a sucky system (yes, stupidity irritates me, particularly when I have to program around it). > > For the purposes of the discussion here though, we have a perfectly good language called VBA to use > to write our applications. To do this little piece in VBA, then call out to AutoIt to do this > little piece, then run more VBA then call autoit, then run VBA... > > C'mon. > > VBA can automate IE, I know that because I have done that. How about we discuss VBA automation of > IE and how a single solution in the language behind Access might solve the problem? > > John W. Colby > www.ColbyConsulting.com > > On 9/10/2010 7:00 AM, Stuart McLachlan wrote: >> I did exactly the same with an application by a paint manufacturer for mixing paints a few >> years ago using AutoIt. Same result. > >