Vulcan .Net and VO 2.8 - yeah right....
in [Visual Objects]
|
From: Ginny Caughey on 3 Oct 2006 19:04 Geoff, > Sorry to enter the fray but I can't resist. What you are doing here is > demonstrating more clearly with every message that Vulcan is thoroughly > aimed at folks who don't want to learn the framework and its very > existence encourages that thinking. Umm do you mean the message where I showed Vulcan code using the Framework? <g> Or perhaps you meant the message where I pointed out that Vulcan includes the source to the compatibility runtime so developers can learn what's happening under the covers. <g> Or maybe it was my message where I encouraged VO developers to get C# Express and start learning .NET so they'd understand what the VO to Vulcan migration was all about. <g> > Then comes the next problem: converting your code from VO to Vulcan. Your > small example in this thread already highlights the dangers to me Why? Much of the code I showed was generated by the VS form editor. The rest was about as simple as it gets - Graham even complained about that! But you're the first to characterize it as dangerous. <g> > of a lot of my VO code because much is not as "nice" as I would like it to > be, especially a lot of late bound 'black box' class code. Well I did try to convince you to use Classmate and strong typing many years ago. <g> But no matter, Vulcan compiles ugly VO code too - probably even yours. Instead of fretting about it, why not just see how well Vulcan works with your code when it's released? There is > going to be significant effort to move our VO code to Vulcan and I suspect > I am better off just putting that effort into new work in Dot net - not > going through the conversion step at all. Only you can make that call. I don't know what your code looks like or how much free time you can spare for rewriting it. But I'd hazard a guess that since you're making money with that code, then it's probably not so bad after all. > And you keep glossing over the resource issue. The stuff for C# out there > (samples, tutorials, books, forums, 3rd party tools and libs) is just > enormous. Vulcan will never match this, never ever and this is a matter of > concern for the developer workshop. And mentioning workshops, this is my > final point. I can now find C# developers to add to my team at the drop of > a hat. For VO (and obviously Vulcan), I would have to train them. This > won't worry the individual or contractor but it is of concern to the > workshop. I assume if you have C# developers you'd put them to work writing C#. What's the problem with that? Ginny > > Geoff > > > > "Ginny Caughey" <ginny.caughey.online(a)wasteworks.com> wrote in message > news:4ofk4vFe6ragU1(a)individual.net: > >> Graham, >> >> I have lots of C# code that doesn't use sender and System.EventArgs, and >> I >> bet you do too. But if a .NET developer needs them, they're there, and >> until >> then he can ignore them even though the forms editor generates the >> correct >> code to handle them. >> >> I also didn't show 1000s of lines of ordinary VO code inside a button >> click >> event handler, but you could do that too, and that's something you can't >> do >> with C#. >> >> -- >> Ginny >> >> >> "Graham McKechnie" <gmknospam(a)bigpond.net.au> wrote in message >> news:YQwUg.40765$rP1.34548(a)news-server.bigpond.net.au... >> >> > Hi Ginny, >> > >> > Thanks for the translation... but you have picked on an event that any >> > VOer would understand. Thats not what I was getting at, as it has >> > nothing >> > to do with the framework, except for the first line which none of them >> > understood, because at first glance they wouldn't have even noticed it. >> > >> > You just blew over System.EventArgs and sender - pretty important stuff >> > from .Net point of view. Just the fact that neither is being used here, >> > should set their minds thinking.. >> > >> > Graham >> > >> > >> > "Ginny Caughey" <ginny.caughey.online(a)wasteworks.com> wrote in message >> > news:4of1vkFeci4kU1(a)individual.net... >> >> >> Graham, >> >> >> >> >>> But that is my point, if you get framework code you have to >> >>> understand >> >>> it, its not VO code anymore, so why try to understand it in VO/Vulcan >> >>> code or whatever you want to call it, when you might as well learn it >> >>> from C# code, where at least it is very well documented by MS and >> >>> then >> >>> by the zillions of examples on the net. >> >> >> >> >> This really isn't hard: >> >> >> >> PRIVATE METHOD btnLoad_Click( sender AS OBJECT, e AS >> >> System.EventArgs ) >> >> AS VOID >> >> if dbf == null >> >> dbf := VulcanDB.DbfRdd{} >> >> endif >> >> isOpen := dbf:Open("c:\vo27b-1\samples\gstutor\customer.dbf", true, >> >> false) >> >> btnSkip:Enabled := true >> >> btnClear:Enabled := true >> >> btnAppend:Enabled := true >> >> btnDelete:Enabled := true >> >> btnUpdate:Enabled := true >> >> Self:Form1_Scatter() >> >> RETURN >> >> >> >> It's Vulcan code, but any VO developers can read it. I dare say most >> >> C# >> >> developers can too, but in case you can't <g>, here's the C# version: >> >> >> >> private void btnLoad_Click(object sender, EventArgs e) >> >> { >> >> if (dbf == null) >> >> dbf = new VulcanDB.DBFRdd(); >> >> isOpen = dbf.Open(@"c:\vo27b-1\samples\gstutor\customer.dbf", true, >> >> false); >> >> btnSkip.Enabled = true; >> >> btnClear.Enabled = true; >> >> btnAppend.Enabled = true; >> >> btnUpdate.Enabled = true; >> >> btnDelete.Enabled = true; >> >> this.Form1_Scatter(); >> >> } >> >> >> >> >> >> What we have here is Vulcan language using the Framework and it's no >> >> more >> >> mysterious than using Classmate or any other alternative GUI classes >> >> in >> >> VO. The form was generated using the VS form editor, and double >> >> clicking >> >> on the form brings up the code editor for writing Load (like PostInit) >> >> code. Double clicking on a button opens the editor for writing button >> >> click code. I'll go out on a limb here at state any VO developer who >> >> can't get a handle on this stuff after reading the Vulcan Getting >> >> Started >> >> docs and trying it with the VS wouldn't be able to learn C# either. >> >> >> >> Ginny >> >> >> > >> >> > >
From: Graham McKechnie on 3 Oct 2006 20:43 Ginny, > Sure so do I. But we both learned all that stuff as we needed to. Yeh, but that was four years ago. We've had the luxury of time to digest two versions of the framework - these guys here don't have that luxury anymore. They have left it far too late, despite all the warnings from you and others etc.. believing that VO or Vulcan would save the day. From my point of view, I can't see Vulcan being of any use to a VOer looking to move to .Net because they are screwed on day 1 because they have no knowledge of the framework. Ironically, the only people, I can see that would benefit from Vulcan are guys like you and me - we did our homework<g> Well you can count me out, because I certainly don't need it anymore, but I can see the advantage to you, because you do already know the framework. I can also partially understand why you don't want to convert your apps to C# directly. I didn't share your concern re rewriting my apps and saw a rewrite as the correct decision at the time. I also wasn't prepared to wait for some unknown product that still doesn't exist. I'd also accept, you can probably justify your case in waiting - doing it on the drip just may work out well for you, but I'd bet you would have preferred to have started just a touch earlier and from what you said yesterday re wanting it all in the same solution, I presume you and the other "exclusive club" members are still waiting and therefore Vulcan is going to be a long time off yet. So now the VOers who have waited too long are faced with either sticking with VO or getting stuck into .Net one way or the other. I don't think sticking with VO is much of an option, unless they are planning on retiring, and of course we all now know 2.8, when it eventually arrives will be the last version of VO as uncle Phil annouced a few days back If they are going to learn .Net then C# is the only way to go, because that is what all the readily available resources are written in - there is and will be nothing of consequence written in Vulcan. You surely wouldn't argue that they should learn C#, so that they can convert their code to Vulcan, but in effect that is what they will have to do just to use Vulcan. I got yelled at for using the word "insane" a couple of weeks ago, but its shrieking out at me again. More and more developers are going to come to the same conclusion that Craig did. Having done it, I don't really understand all the fuss. If there was any pain, I can assure you I've long forgotten it. > If Craig's system he's rewriting uses DBF files today, then he has some > choices to make. If I were doing a total rewrite, I might not continue to > use DBF files either, but if I'm migrating DBF-based code rather than > laboriously rewriting it, then I'd keep the DBF files too. And if Craig's > clients have data in DBF files, they'll probably want to keep the data > even if they change to SQL for data storage. In any case, the clients may > not care what language you use (and usually don't) but they do tend to > have opinions about how the data should be stored. I have some that say > they prefer DBF files, and their money is good too. Sure Craig was using dbf's and I would think that is one of the main reasons why he made his decision. I think in his case it just might be the client who are demanding Sql. I'm also pretty sure he mentioned that the clients are also specifing that he use a commonly used .Net language. But it would be better to ask Craig than me. Then again you could ask Phil, he knows what going in everyone's business<g>. "Ginny Caughey" <ginny.caughey.online(a)wasteworks.com> wrote in message news:4ofrf2Fec254U1(a)individual.net... > Graham, > >>> I have lots of C# code that doesn't use sender and System.EventArgs, and >>> I bet you do too. >> >> Yes, but as you are aware from my GPS code for instance, I also have a >> heap of code that does, using my own classes that inherit from >> System.EventArgs. > > Sure so do I. But we both learned all that stuff as we needed to, and it's > possible to write whole apps that don't use it. > >> I don't think you can just brush off the importance of the C# event >> system, which is way different to anything VO ever had. > > Not at all, I think it's cool. > > Obviously Vulcan now has >> that, so they better get around to learning how to use it. What were we >> up to before, day 3 or day 4, its still learn the framework day. I'm >> still learning it after 4 years of it and I guess you are too. > > Yep, learning new stuff all the time. Gradual is the way to go. > >>> I also didn't show 1000s of lines of ordinary VO code inside a button >>> click event handler, but you could do that too, and that's something you >>> can't do with C#. >> >> Oh yes, but that is something I don't want to do or see with C#<g>. I >> don't want to stay with VO code or dbfs, that kind of stuff has been >> replaced long ago. > > That's fine for you, but not everybody has the same needs as you. > > I hope you are not suggesting that VOers should remain with their dbfs >> etc, with their corrupted indexes and data integrity problems etc. as >> they move to .Net. > > Lots of VO developers no longer use DBFs already. But I have C# code that > accesses DBF files because I NEED to do that, and other VO developers may > need to on occasion too. In fact, the utility that loads my clients' DBF > data into SQL Server tables as they migrate to the SQL version of my > products happens to be written in C#. I could have written it in VO but > just didn't. > > I'm sure that sort of approach would not help Craig or any >> other VOer one bit in their move to .Net. > > If Craig's system he's rewriting uses DBF files today, then he has some > choices to make. If I were doing a total rewrite, I might not continue to > use DBF files either, but if I'm migrating DBF-based code rather than > laboriously rewriting it, then I'd keep the DBF files too. And if Craig's > clients have data in DBF files, they'll probably want to keep the data > even if they change to SQL for data storage. In any case, the clients may > not care what language you use (and usually don't) but they do tend to > have opinions about how the data should be stored. I have some that say > they prefer DBF files, and their money is good too. > > Talk about bringi
From: Sherlock on 3 Oct 2006 20:37 Geoff The issue of .NET is an object model wrapper around the WINAPI and an MSIL allows you to intermix other languages libraries. So VULCAN has the VisualStudio IDE and all the .NET code and libraries that exist. Therefore VULCAN code which Graham and you push does more with less code is going to be fine. snip[ Vulcan is thoroughly aimed at folks who don't want to learn the framework and its very > existence encourages that thinking.] It is a .NET language which operates using the framework so how can anybody using not learn the framework ? -- snip[ And you keep glossing over the resource issue. The stuff for C# out there (samples, tutorials, books, forums, 3rd party tools and libs) is just enormous. Vulcan will never match this, never ever ] It does not have to..... you can call and use it from VULCAN anyway. -- snip[ For VO (and obviously Vulcan), I would have to train them. This won't worry the individual or contractor but it is of concern to the workshop. ] If I was trained by Geoff this would worry me too.. <BG> Phil McGuinness
From: Ginny Caughey on 3 Oct 2006 21:59 Graham, > Yeh, but that was four years ago. We've had the luxury of time to digest > two versions of the framework - these guys here don't have that luxury > anymore. They have left it far too late, despite all the warnings from you > and others etc.. believing that VO or Vulcan would save the day. I don't think the later adapters really felt any need for .NET until perhaps recently, and during those four or more years the framework has matured a bit and Visual Studio has matured a lot. So although that wasn't my choice or yours, I think better late than never is the right attitude. > From my point of view, I can't see Vulcan being of any use to a VOer > looking to move to .Net because they are screwed on day 1 because they > have no knowledge of the framework. Ironically, the only people, I can see > that would benefit from Vulcan are guys like you and me - we did our > homework<g> People who do their homework always have an advantage, but I can't imagine which VOer you might be thinking of that is screwed because he didn't bother to learn something new. I see VO developers at conferences several times a year - I see some at Microsoft conferences too - and they're all there to learn new things. From my point of view, if they could learn to produce great apps using VO 1, or even VO 2, they're some of the most resourceful developers in the world. They'll love .NET and Visual Studio once they're into it, and they won't find learning the Framework hard at all - they'll just learn what they need as they need it. > Well you can count me out, because I certainly don't need it anymore, but > I can see the advantage to you, because you do already know the framework. > I can also partially understand why you don't want to convert your apps to > C# directly. I didn't share your concern re rewriting my apps and saw a > rewrite as the correct decision at the time. I also wasn't prepared to > wait for some unknown product that still doesn't exist. Understood. It's not an emotional decision for me - it's a business one, as perhaps you understand now. You made a business decision too I assume. > I'd also accept, you can probably justify your case in waiting - doing it > on the drip just may work out well for you, but I'd bet you would have > preferred to have started just a touch earlier and from what you said > yesterday re wanting it all in the same solution, I presume you and the > other "exclusive club" members are still waiting and therefore Vulcan is > going to be a long time off yet. On the one hand it would have been nice to move everything to .NET sooner, but on the other I feel fortunate that my business continues to keep me so busy. It's no secret that Vulcan isn't released yet, but I don't think it's "a long time off". It's not of critical importance to me when Vulcan is released though as long as Grafx gets it right. I just need it eventually. Whatever I've needed in .NET already, I've done in C#. > and of course we all now know 2.8, when it eventually arrives will be the > last version of VO as uncle Phil annouced a few days back Although I do hope that 2.8 is the last version of VO that I use, I have it on good authority that it will not be the last version that Grafx produces. Maybe it will be like Clipper 5.3... > You surely wouldn't argue that they should learn C#, so that they can > convert their code to Vulcan, but in effect that is what they will have to > do just to use Vulcan. I got yelled at for using the word "insane" a > couple of weeks ago, but its shrieking out at me again. Nope, they don't have to learn C# to use Vulcan. They would be better Vulcan developers if they know C# though. Similarly spending time with Petzold and working some in C made me a better VO developer. Perhaps the same was true for you and others as well, and I don't think that's insane at all. > More and more developers are going to come to the same conclusion that > Craig did. I don't think we'd be having this discussion if that were really the case. Some VO developers are hoping they can retire before they have to make a decision, and many more expectVulcan to ease the path for them when they're ready. A few like you have actually rewritten VO apps in C# (and I've rewritten a couple of smaller ones myself which is part of the reason I'm not doing more of it), but not many people are rewriting big ones that I'm aware of. If you're busy with other work, there just isn't the business justification. Ginny
From: Geoff Schaller on 3 Oct 2006 22:38
Ginny, > Umm do you mean the message where I showed Vulcan code using the Framework? > <g> Or perhaps you meant the message where I pointed out that Vulcan ....all those. You want your cake and to eat it too. Either Vulcan is being used to hide the framework or its not. If the rationale is to avoid the framework then Vulcan is of no value. You may as well stay with pure VO. If the rationale is to get into the framework then Vulcan will help you get there at the expense of an extra step - converting from VO to Vulcan and the converting your code to use the framework. I am advocating one step. Skip the Vulcan step. Go straight to the framework. It will be new stuff anyhow. > Why? Much of the code I showed was generated by the VS form editor. The rest > was about as simple as it gets - Graham even complained about that! But > you're the first to characterize it as dangerous. <g> That's ok, you misunderstanding is understandable <g> > Well I did try to convince you to use Classmate and strong typing many years > ago. <g> But no matter, Vulcan compiles ugly VO code too - probably even Well the reason I didn't (and thank God I didn't!) was that CM was just too obscure. It would have cut me off from the broader VO community and limited my ability to use things like bBrowser and my already constructed class libraries. And in this I am seeing parallels in the Dot net world with Vulcan. Something essentially OK in its own right but gee... so obscure. > Instead of fretting about it, why not just see how well Vulcan works > with your code when it's released? Who's fretting? I've said a Brian-million times that I will test it. I get a copy from Brian when it is eventually released. I just have little faith it will work as smoothly as you think. If anyone, it is you fretting about our expectations. Relax. Time will tell. > I assume if you have C# developers you'd put them to work writing C#. > What's the problem with that? Nothing. My point was that I can find them. A dime for a dozen. They fall off trees around here (think of your own metaphors <g>). But Vulcan ones????? Geoff |