Prev: Vo 2.7 Garbage Collector
Next: CRC32
From: Markus Feser on 13 Nov 2006 03:28
"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
>

From: hei_mue on 13 Nov 2006 04:40
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: hei_mue on 13 Nov 2006 04:52
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: E?!k V!sser on 13 Nov 2006 05:14
Heiko,

> Be I the only one who can see this fact?

Could it be you see this wrong and woul that explain why you are the only
one who sees this?

Erik




"hei_mue" <h.mueller(a)wincontent.de> schreef in bericht
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: hei_mue on 13 Nov 2006 05:47
> > Be I the only one who can see this fact?Could it be you see this wrong and woul that explain why you are the only
> one who sees this?

Have you seen the conversion of a window to VULCAN which includes
CustomControls and/or Controls created from derived classes?

Of course you can map the most call of a VO-Methods to an equivalent
..NET-'Method' for example:

SingleLineEdit:Hide() to TextBox.Visible=false;

But I have no clue how this can be done in with things like this:

METHOD Dispatch(oEvent) CLASS mlSingleLineEditChoice
//Event auswerten
LOCAL iMessage AS DWORD
LOCAL sCalcSizeParams AS _winNCCalcSize_Params
LOCAL srcArea IS _winRect
LOCAL sptOrigin IS _winPoint
LOCAL uResult AS USUAL

// Message auswerten
iMessage := oEvent:uMsg
IF iMessage=WM_NCHITTEST
// Position der Maus auswerten
sptOrigin.X := SHORT(_CAST, LoWord(oEvent:LParam))
sptOrigin.Y := SHORT(_CAST, HiWord(oEvent:LParam))
ScreenToClient(SELF:Handle(), @sptOrigin)
SELF:GetButtonArea(@srcArea)
IF PointInRect(@srcArea, sptOrigin.X, sptOrigin.Y)
SELF:EventReturnValue := HTCHOICE
RETURN SELF:EventReturnValue
ENDIF
ELSEIF iMessage=WM_GETDLGCODE
// welche Eingaben sind von Interesse?
IF oEvent:WParam=VK_RETURN
IF (GetKeyState(VK_CONTROL)>>15)<>0
PostMessage(SELF:Handle(), CEM_CHOICEOPEN, 0, 0)
ENDIF
ELSEIF oEvent:WParam=VK_TAB .and. (GetKeyState(VK_RETURN)>>15)<>0
// ClipperKeys sind aktiv und die Return-Taste wurde gedrückt !!
IF (GetKeyState(VK_CONTROL)>>15)<>0
PostMessage(SELF:Handle(), CEM_CHOICEOPEN, 0, 0)
SELF:EventReturnValue := DLGC_WANTTAB
RETURN DLGC_WANTTAB
ENDIF
ENDIF
ELSEIF iMessage=WM_NCCALCSIZE
// Client-Area berechnen
uResult := SUPER:Dispatch(oEvent)
IF LOGIC(_CAST, oEvent:WParam)
sCalcSizeParams := PTR(_CAST, oEvent:LParam)
sCalcSizeParams.rgrc[1].Right -= GetSystemMetrics(SM_CXVSCROLL)
ENDIF
RETURN uResult
ELSEIF iMessage=WM_NCLBUTTONDOWN
// Bereich unter der Maus auswerten
IF LoWord(oEvent:WParam)=HTCHOICE
// Auswahl öffnen oder schließen
IF SELF:lChoiceOpen
SendMessage(SELF:Handle(), CEM_CHOICECLOSE, 0, 0)
ELSE
SendMessage(SELF:Handle(), CEM_CHOICEOPEN, 0, 0)
ENDIF
SELF:EventReturnValue := ISEXECUTED
RETURN SELF:EventReturnValue
ENDIF
ELSEIF iMessage=WM_NCPAINT
// None-Client-Area zeichnen
uResult := SUPER:Dispatch(oEvent)
SELF:DoDrawButton()
RETURN uResult
ELSEIF iMessage=WM_SHOWWINDOW
IF !LOGIC(_CAST, oEvent:WParam)
// Control wird ausgeblendet
IF SELF:lChoiceOpen
SELF:OnChoiceClose()
ENDIF
ENDIF
ELSEIF iMessage=CEM_CHOICEOPEN
// Auswahl öffnen
SELF:OnChoiceOpen()
SELF:EventReturnValue := ISEXECUTED
RETURN SELF:EventReturnValue
ELSEIF iMessage=CEM_CHOICECLOSE
// Auswahl schließen
SELF:OnChoiceClose()
IF oEvent:WParam=1
// RETURN-Taste als WM_KEYDOWN schicken
PostMessage(SELF:Handle(), WM_KEYDOWN, KeyEnter, 0)
ENDIF
SELF:EventReturnValue := ISEXECUTED
RETURN SELF:EventReturnValue
ELSEIF iMessage=CEM_ISCHOICEOPEN
IF SELF:lChoiceOpen
SELF:EventReturnValue := 1
ELSE
SELF:EventReturnValue := 0
ENDIF
RETURN SELF:EventReturnValue
ENDIF
RETURN SUPER:Dispatch(oEvent)

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.

Heiko Mueller

PS: Its not my intention to provoke anybody with this messages - I'm
really interested in a technical and seriuos discussion. I have here
some relativ large VO-Applications and for now I will evaluate the best
way to bring this to .NET. 80% of the source of this Apps are
GUI-related (many CustomControls and such things). At this time I think
and feel that a complete rewrite in C# is the best way to bring this
Apps to .NET. But may be there are some facts that can 'retune' me...

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Prev: Vo 2.7 Garbage Collector
Next: CRC32