Re: If VB.NET had CL macros....

On Sep 26, 7:30 pm, "Dimiter \"malkia\" Stanev" <mal...@xxxxxxxxx>
wrote:
Today I had to tweak one of our internal tools written in VB.NET, and
wish so much that there be macros... but I knew there ain't.

Here is the problem: on .NET if you want to update a GUI control from
the non-main thread, you have to make a delegate, prepare an invocation,
put the parameters and call it. For example:

Public Sub UpdateConnectionStatus(ByVal connectionOK As Boolean)
If (connectionOK) Then
form.ConnectionLost.Hide()
form.ConnectionOK.Show()
Else
form.ConnectionOK.Hide()
form.ConnectionLost.Show()
End If
End Sub

Basically this simple sub would be called with True or False, whether
the image displaying ConnectionLost would be shown, or the ConnectionOK.

anyhow, calling this code from the non-main thread does not work. So
here is some "awesomeness" you have to do to achieve this:

Public Delegate Sub UpdateConnectionStatusDelegate(ByVal
connectionOK As Boolean)

Public Sub UpdateConnectionStatus(ByVal connectionOK As Boolean)
If (form.InvokeRequired()) Then
form.Invoke(New UpdateConnectionStatusDelegate(AddressOf
UpdateConnectionStatus), New Object() {connectionOK})
ElseIf (connectionOK) Then
form.ConnectionLost.Hide()
form.ConnectionOK.Show()
Else
form.ConnectionOK.Hide()
form.ConnectionLost.Show()
End If
End Sub

But the question is why? Why in first place Microsoft invented such
dumb way of doing the things, and why there wasn't any band-aid
provided? That's not the only place, it's all over.

And if VB.NET just had macroses - it would've been way easier.

Choice of Language Do Matter. I don't care whether it's .NET or any
other runtime, it's about the language. And VB.NET sucks big time!

Before asking me why VB.NET was chosen for that particular application,
is simply because VB is thought of the easiest language for a scripter,
designer, any non-heavy programmer type, but creative.

Why are you posting this on c.l.l instead of some VB.NET list?

.