And now the news from VODC Germany
in [Visual Objects]
|
Prev: Vo 2.7 Garbage Collector
Next: CRC32
From: E?!k V!sser on 13 Nov 2006 06:12 Heiko, > Have you seen the conversion of a window to VULCAN which includes > CustomControls and/or Controls created from derived classes? Nope, the VO GUI classes were not available yet. But there is no need for the transporter to map VO GUI towards .NET equivalents at the time the VO GUI classes compiles. > SingleLineEdit:Hide() to TextBox.Visible=false; This can stay SingleLineEdit:Hide() > But I have no clue how this can be done in with things like this: ...... > Of course I can write the same funtionality in .NET (and in fact I have > done this with the code that you can see here) but I dont think that > this can be done automatically. I do not see a reason why your dispatcher would not work in Vulcan (using the VO GUI classes). Chrys Pyrgas showed in one of hs sessons the basics of how you could combine VO GUI with .NET GUI. Not a full size demo, so you have to wait a little for that. In fact, the plan is (under restriction the VO GUI compiles) that he is going to show it in Holland next month So Vulcan is going to provide you a smooth migration path. You can compile your VO app (perhaps with some minor adjustments) and implement all new features available in the .NET framework. > PS: Its not my intention to provoke anybody with this messages - I'm > really interested in a technical and seriuos discussion. OK, i understand. We all are in more or less the same position as you! You really sould come to one of the conference and let you convice. Next occasion will be in Holland with 4 out of 5 sessions in English by Chrys and Meinhard and next spring in London. regards, Erik
From: Ginny Caughey on 13 Nov 2006 07:00 Heiko, Yes you can do the whole CodeDom thing in Vulcan too just as you suggest. As far as I know that's more or less how macros are implemented in Vulcan anyway. But with Vulcan you also have the option of just easily using macros like in VO. -- Ginny "hei_mue" <h.mueller(a)wincontent.de> wrote in message news:1163410811.581495.65600(a)i42g2000cwa.googlegroups.com... > Hi Markus, > > Markus Feser schrieb: >> in Vulcan >> s := "System.Environment.CurrentDirectory" >> ? &s > > This isn't very impressive. Encapsulate the Compiler-Calling in a > simple static method (? is nothing other) is easy. But the allways > available Compilers in .NET can do much more for you... > > Here is a simple Method that creates a Class from Sourcecode that is > consigned as string (think about storing classes in a Database for > really DataDrivern-Applications): > > At First 'How To call this in your own Source'... > > object > oMyObject=ClassHelper.CreateFromSource(sMySource,"TestClass",this,new > ArrayList()) > > And this is the Code (only a smale example - for 'real world use' you > shouldt have to add a better errror-handling (try catch finally): > > public static object CreateFromSource(string sSource, string > sClassName, object oOwner, ArrayList aAssemblies) > { > CodeDomProvider oCompiler = new CSharpCodeProvider(); > CompilerParameters oParameters = new CompilerParameters(); > CompilerResults oResult; > Assembly oAssembly; > object oReturn = null; > > aAssemblies.Add("System.dll"); > aAssemblies.Add("System.Data.dll"); > aAssemblies.Add("System.Xml.dll"); > foreach (string sAssembly in aAssemblies) > { > oParameters.ReferencedAssemblies.Add(sAssembly); > } > oParameters.GenerateInMemory = true; > > oResult = oCompiler.CompileAssemblyFromSource(oParameters, sSource); > > if (oResult.Errors.HasErrors) > { > string sMessage = ""; > sMessage = oResult.Errors.Count.ToString() + " Fehler : "; > for (int x = 0; x < oResult.Errors.Count; x++) > { > sMessage += "\r\nLine : " + oResult.Errors[x].Line.ToString() > + " - " + oResult.Errors[x].ErrorText; > } > MessageBox.Show("Fehler beim erzeugen der Klasse.\r\n"+sMessage); > } > > oAssembly = oResult.CompiledAssembly; > > oReturn = oAssembly.CreateInstance(sClassName, false, > BindingFlags.CreateInstance, null, new object[] { oOwner }, > System.Globalization.CultureInfo.CurrentCulture, null); > if (oReturn == null) > { > MessageBox.Show("Objekt der Klasse "+sClassName+" konnte nicht > erzeugt werden."); > return oReturn; > } > > return oReturn; > } > > As you can see: The CodeDom-Provider in .NET is much more then a simple > ? in VO... > > Heiko Mueller > > PS: Of course you can do all this things in Vulcan (I hope this for > you). Its not Vulcan or C# or whatever - its .NET... >
From: Markus Feser on 13 Nov 2006 07:10 > > in Vulcan > > s := "System.Environment.CurrentDirectory" > > ? &s > This isn't very impressive. Encapsulate the Compiler-Calling in a > simple static method (? is nothing other) is easy. But the allways > available Compilers in .NET can do much more for you... >.... >.... >.... > As you can see: The CodeDom-Provider in .NET is much more then a simple > ? in VO... > > Heiko Mueller > > PS: Of course you can do all this things in Vulcan (I hope this for > you). Its not Vulcan or C# or whatever - its .NET... Hello Heiko, ??? I don't see your point, what did the ? have to do with macros? I refer to the &-Operator Everything what you and Rob describe is also possible in Vulcan and in ALL other .NET languages. See the Common Language Specifications (CLS). One benefit of a JIT-Compiler But in Vulcan you can do it additional in a very easy way The same way as in VO, but with more possibilities. Your C# sample create a DataDriven object. That is something, that I use in VO for a long time. Nothing that is new for a Visual Objects programmer. That is only one part of VO macros. Regards, Markus Feser > Here is a simple Method that creates a Class from Sourcecode that is > consigned as string (think about storing classes in a Database for > really DataDrivern-Applications): > > At First 'How To call this in your own Source'... > > object > oMyObject=ClassHelper.CreateFromSource(sMySource,"TestClass",this,new > ArrayList()) > > And this is the Code (only a smale example - for 'real world use' you > shouldt have to add a better errror-handling (try catch finally): > > public static object CreateFromSource(string sSource, string > sClassName, object oOwner, ArrayList aAssemblies) > { > CodeDomProvider oCompiler = new CSharpCodeProvider(); > CompilerParameters oParameters = new CompilerParameters(); > CompilerResults oResult; > Assembly oAssembly; > object oReturn = null; > > aAssemblies.Add("System.dll"); > aAssemblies.Add("System.Data.dll"); > aAssemblies.Add("System.Xml.dll"); > foreach (string sAssembly in aAssemblies) > { > oParameters.ReferencedAssemblies.Add(sAssembly); > } > oParameters.GenerateInMemory = true; > > oResult = oCompiler.CompileAssemblyFromSource(oParameters, sSource); > > if (oResult.Errors.HasErrors) > { > string sMessage = ""; > sMessage = oResult.Errors.Count.ToString() + " Fehler : "; > for (int x = 0; x < oResult.Errors.Count; x++) > { > sMessage += "\r\nLine : " + oResult.Errors[x].Line.ToString() > + " - " + oResult.Errors[x].ErrorText; > } > MessageBox.Show("Fehler beim erzeugen der Klasse.\r\n"+sMessage); > } > > oAssembly = oResult.CompiledAssembly; > > oReturn = oAssembly.CreateInstance(sClassName, false, > BindingFlags.CreateInstance, null, new object[] { oOwner }, > System.Globalization.CultureInfo.CurrentCulture, null); > if (oReturn == null) > { > MessageBox.Show("Objekt der Klasse "+sClassName+" konnte nicht > erzeugt werden."); > return oReturn; > } > > return oReturn; > } > > As you can see: The CodeDom-Provider in .NET is much more then a simple > ? in VO... > > Heiko Mueller > > PS: Of course you can do all this things in Vulcan (I hope this for > you). Its not Vulcan or C# or whatever - its .NET... >
From: Ginny Caughey on 13 Nov 2006 07:13 Heiko, As John said, the Vulcan Transporter actually provides two options for moving GUI code to Vulcan. One is to just take the existing VO code that uses the VO GUI classes and move it as it is. Once the VO GUI classes are compiling correctly (and Don says he is almost there) then this would be the quickest way to get VO code to Vulcan and all your custom controls should continue to work as they always did (except .NET would be providing garbage collection services.) But the second approach is to have Transporter ADDITIONALLY create Visual Studio forms using Windows.Forms in the same project. You don't have to use this form at all, but if you want to do so, then you have the beginnings of a Windows Form form already in your project (but with a slightly different name) which you might want to use later at some point You might want to eventually do this with all your VO forms, or maybe only some of them.. You could even use the Windows clipboard to move these Visual Studio forms to C# by copying them from the Vulcan project and simply pasting them into a C# project's form editor. Of course if you past the forms into a C# project, you would then write your event handlers in C# instead of Vulcan. And if you keep them in Vulcan, then of course you use Vulcan syntax. I think this is very powerful because it lets you choose how and when to migrate VO forms but still avoids the very tedious process of redrawing all your VO forms that you do want to change into Windows.Forms forms eventually. (I know how boring this kind of work is because I have done it.) I think when the Getting Started with Vulcan.NET at Warp Speed book is available for download then everybody will have a better idea how this all works. -- Ginny "hei_mue" <h.mueller(a)wincontent.de> wrote in message news:1163411549.537382.62660(a)m7g2000cwm.googlegroups.com... > John Parker schrieb: >> Next up was Paul Piko who demonstrated the Vulcan.Net Transporter. This >> utility is designed to achieve two goals. The first is to provide a >> series >> of code improvements that are applied directly to the source code in a >> selected VO repository. These improvements arise from the continued >> tightening of the language, which assists the compiler in producing a >> more >> robust output. The second goal is to extract the entities from the VO >> project and automatically create a Vulcan.NET Visual Studio solution. The >> Transporter also takes the proprietary VO window entity and produces >> source >> code that uses the .NET framework classes so that it can be edited using >> the >> Visual Studio form designer. > > Good to know that my decision to switch to C# was the absolut right > one. This facts say to me, that a conversion to .NET without rewrite > the most GUI-Code is not possible. This way of 'Transportation' is only > feasible with VO-StandardWindows and VO-StandardControls. All > CustomControls and the most of our own methods in derived classes will > not work correct / or will not work correct after this way of > conversion. I think this will break many many code and is one of the > fact that a switch from VO to VULCAN is not much differently from a > switch from CLIPPER to VO - and you guys should know what this means... > > Be I the only one who can see this fact? > > Heiko Mueller >
From: rob on 13 Nov 2006 08:14
Markus, Are you kidding me? That is exactly what we moved away from, CodeDOM is the way to go. How would you execute the sample code below using macros? Also, with macros what if you wanted to add a reference to another assembly (at runtime) and execute some of it's code? I SERIOUSLY doubt that would be possible. Sample Code: ------------------- Dim myCollection AS System.Collections.Generics.List( Of System.Int32 ) For Each item As System.Int32 IN myCollection If Item > 10 Me.DoSomething() EndIf Next Cheers, Rob Markus Feser wrote: > "rob" <rob_panosh(a)asdsoftware.com> schrieb im Newsbeitrag > news:1163176292.970140.220880(a)k70g2000cwa.googlegroups.com... > > Rob, > > in Vulcan > > s := "System.Environment.CurrentDirectory" > ? &s > > Regards, > Markus Feser > > > > Markus, > > > > I have a complete scripting object (which I cannot send because it's > > embedded in our application) wrapper around the compiler services. But > > I can show you an example on how we compile into a .DLL in our > > application. We also have instances where we compile in secondary > > application domain so references to Assemblies can be released. Also, > > if you are looking for a good editor in your application (with > > intellisense) to use to write your source code then take a look at > > http://www.qwhale.net, it supports C#.Net, VB.Net, XML, HTML, and many > > other languages. > > > > Sample Code: > > 'Defined in the class dec. > > Private Shared _provider As New Microsoft.VisualBasic.VBCodeProvider > > Private _compileParameters As New > > System.CodeDom.Compiler.CompilerParameters > > Private _compileResults As System.CodeDom.Compiler.CompilerResults > > > > 'Now configure the compile environment. Note: References are added in > > me.New() > > If production Then > > 'REP: 08.28.2006 - To be compatible with pv 4.5 calc strings we > > need script off. > > Me._compileParameters.CompilerOptions = "/optionstrict-" ' & > > rootNameSpace > > Else > > Me._compileParameters.CompilerOptions = "/optionstrict+" ' & > > rootNameSpace > > End If > > > > Me._compileParameters.GenerateInMemory = True > > Me._compileParameters.GenerateExecutable = False > > Me._compileParameters.WarningLevel = 4 > > Me._compileParameters.IncludeDebugInformation = False > > Me._compileParameters.TreatWarningsAsErrors = True > > Me._compileParameters.TempFiles.KeepFiles = False > > > > If Not Me._compileResults Is Nothing Then > > Me._compileResults.Output.Clear() > > End If > > > > 'Compile the source code. > > Me._compileResults = > > _provider.CompileAssemblyFromSource(Me._compileParameters, > > Me.ProductionSourceCode) > > > > 'This is the assembly we invoke our members (Properties and Methods). > > Me._productionAssembly = Me._compileResults.CompiledAssembly > > > > ... > > > > Cheers, > > Rob Panosh > > > > Markus Feser wrote: > > > > Yes ... Visual Basic.Net, C#.Net ... It's NOT magic. All you need to > > > > do is use the .NET compiler services. > > > > > > > > Rob > > > > > > Hello Rob, > > > > > > can you show us a sample? > > > > > > Regards, > > > Markus Feser > > |