More playtime with CLR/Windows Forms

[stanl]

I attached some modifications to the original post Deana made showing an Richtext box in a Windows form. It will display, but I have two issues and 1 question

1. Proper method to set the background color (code has two shots at it)
2. Proper method to set anchors (to make controls resize with form). I tried the or'd value.

Question:  I believe adding a click event to the button is not possible, and Deana's original post used the dialogresults. What I would like to know is if when the button was clicked it could run a UDF (say something like net use) and return the results to the Richtext Control?

[Deana]

I have been fiddling with setting the backcolor of a form. I currently suspect that it falls into a dotNet limitation in WinBatch. Specifically:

Value types (structures) that only provide a multiple parameter constructor(s) cannot be used.
OR
Class member overloads that rely solely on the return type and name for their signature cannot be used.

[stanl]

I have been fiddling with setting the backcolor of a form.

I did see several postings that indicate setting the backcolor from a hex string.

I'm really more interested in the anchor. I used the numerics (like 12,14) and in Powershell they work great, the objects resize with the form. I didn't try but I think an Or Operation of

anchor.top|anchor.left|anchor.right|anchor.bottom  - combination is the way I saw it in some C# code. But like I said, playtime. I try to dedicate 1 hour a week to learning more about the CLR>

[td]

This seems to work

Code (winbatch) Select Expand

tStyles = ObjectClrType("System.Windows.Forms.AnchorStyles", 14)
RichTextBox1.Anchor = tStyles ;14


[stanl]

This seems to work

Code (winbatch) Select Expand

tStyles = ObjectClrType("System.Windows.Forms.AnchorStyles", 14)
RichTextBox1.Anchor = tStyles ;14


Thanks. I had used ObjectClrType for the Location and Size, so it should have dawned on me to try it with the anchor.

[stanl]

I have been fiddling with setting the backcolor of a form. I currently suspect that it falls into a dotNet limitation in WinBatch. Specifically:

Not to drag this thread out but just for my own understanding...

Code (Winbatch) Select Expand


cColor=ObjectClrNew('System.Drawing.Color')
cName = cColor.FromName("Sienna")
Message("",ObjectTypeGet(cName))


returns UI4 - which I assume are the ARGB values of the color structure. And you tend to believe that falls under

Value types (structures) that only provide a multiple parameter constructor(s) cannot be used.


Bummer. You would think BackColor would be one of the easier properties to deal with.

[JTaylor]

Appreciate all the posts on Windows Forms.   Just wish I could find some "playtime" :)

Jim

[td]

I have been fiddling with setting the backcolor of a form. I currently suspect that it falls into a dotNet limitation in WinBatch. Specifically:

Not to drag this thread out but just for my own understanding...

Code (Winbatch) Select Expand


cColor=ObjectClrNew('System.Drawing.Color')
cName = cColor.FromName("Sienna")
Message("",ObjectTypeGet(cName))


returns UI4 - which I assume are the ARGB values of the color structure. And you tend to believe that falls under

Value types (structures) that only provide a multiple parameter constructor(s) cannot be used.


Bummer. You would think BackColor would be one of the easier properties to deal with.

This is an oddity in the FCL's implementation of the structures and there is really not much that can be done about it. System.Drawing.Color has a lot of static methods that are quit handy but they return an VT_I4 variant when returning a color.  This wouldn't be a problem if all the properties that expect that structure also accepted VT_I4s as an appropriate type.  But as you have discovered many of them don't.  They are expecting some kind of VT_RECORD instead.  This wouldn't be a problem either if the FCL provided an IRECORD interface for the FCL structure so WinBatch could automagically convert the type but it doen't do that either!  It is a catch 22 and ostensible a inconsistency in the implementation of the FCL. C'est la guerre.

[stanl]

This is an oddity in the FCL's implementation of the structures

So stuck in grey. Reminds me of Henry Ford's remark: "You can have a model-T in any color your like as long as it is black."

[td]

I wouldn't go so far are to say you are stuck.  You could probably solve the problem with a little c# and the 'Microsoft.CSharp.CSharpCodeProvider' class. Admittedly, not the most desirable solution but a solution nonetheless.

[stanl]

I wouldn't go so far are to say you are stuck.  You could probably solve the problem with a little c# and the 'Microsoft.CSharp.CSharpCodeProvider' class. Admittedly, not the most desirable solution but a solution nonetheless.

It works quite well going the Powershell route. Background color, image, icon, and even a click event. As to using the CSharpCodeProvider - are you suggesting creating a little assembly and calling it, or can C# be executed 'on the fly' within the WB script?

[NOTE]: I put the wrong WB script in the first attachment. This has been corrected

[stanl]

or can C# be executed 'on the fly' within the WB script?

I noticed a generateInMemory property where OutputAssembly (in the cSharpProvider class) does not need to be specified.  Wouldn't that be a hoot!!!

[td]

Powershell, like the poor, we will have with us always and "GenerateInMemory" is what I had in mind.

[stanl]

Powershell, like the poor, we will have with us always and "GenerateInMemory" is what I had in mind.

Well before I post out the synonyms for arrogance, can you throw us sons of Emma Lazarus a bone of code showing backcolor via "GenerateInMemory".  Please.