TwinBasic

Hello,
I primly work with MS-Access. If I want to try out something, I make a copy of the file.
I'm not familiar with Source-Control etc. jet.
What is the recommended way to work with Tb Versions of a project?
Thanks for useful links, to learn with.

twinBASIC status update:

https://nolongerset.com/twinbasic-up...tember-5-2021/

Highlights include IntelliSense in the Debug Console, unit testing improvements, and the addition of #Error and #Warning directives.

JavaScript has a comma operator, for example:

Code:

---

if (a, b, c, d) {
    ...
    ...
    return e, f, g, h;
}

---

Maybe twinBasic could add a similar operation, that is, use a colon instead of the comma operator, for example:

Code:

---

If (a: b: c: d) Then
...
...
End If

---

The above is equivalent to:

Code:

---

Call a
Call b
Call c

If d Then
...
...
End If

---

What an odd syntax, can lead to a lot of confusion

Quote:

---

Originally Posted by Arnoutdv

What an odd syntax, can lead to a lot of confusion

---

The part is a bit confusing, but the whole is clearer.

Most syntactic sugar is more confusing for beginners, but once they are familiar and used to these syntactic sugars, they seem to rely more and more on syntactic sugar.

Quote:

---

Originally Posted by SearchingDataOnly

The part is a bit confusing, but the whole is clearer.

Most syntactic sugar is more confusing for beginners, but once they are familiar and used to these syntactic sugars, they seem to rely more and more on syntactic sugar.

---

VB.Net has a similar idea using Tuples behind the scenes

Code:

---

Imports System.Globalization

Public Module NumericLibrary
    Public Function ParseInteger(value As String) As (Success As Boolean, Number As Int32)
        Dim number As Integer
        Return (Int32.TryParse(value, NumberStyles.Any, CultureInfo.InvariantCulture, number), number)
    End Function
End Module

---

That snippet is from https://docs.microsoft.com/en-us/dot...-return-values

Quote:

---

Originally Posted by PlausiblyDamp

VB.Net has a similar idea using Tuples behind the scenes

Code:

---

Imports System.Globalization

Public Module NumericLibrary
    Public Function ParseInteger(value As String) As (Success As Boolean, Number As Int32)
        Dim number As Integer
        Return (Int32.TryParse(value, NumberStyles.Any, CultureInfo.InvariantCulture, number), number)
    End Function
End Module

---

That snippet is from https://docs.microsoft.com/en-us/dot...-return-values

---

VB.NET has a lot of excellent syntactic sugar. Although I will never use VB.NET, I have been absorbing some valuable syntax from VB.NET syntactic sugar.

However, the tuple of VB.NET and the comma operator of JS are completely different concepts, and their uses are also completely different.

Code:

---

if (a, b, c, d) {
    ...
    ...
    return e, f, g, h;
}

---

The above is equivalent to:

Code:

---

a;
b;
c;
if (d){
    ...
    ...
    e;
    f;
    g;
    return h;
}

---

Since a, b, c, d are a group of closely related statements/expressions, putting them in parentheses makes the whole code block clearer: (a, b, c, d)

Similarly, e, f, g, and h are also a group of closely related statements/expressions, so they are also placed in the parentheses: (e, f, g, h)

Hmmm.
I often use the following construct in VB6

Code:

---

Public Function myFunction(lInput As Long, sInput As String, ByRef lReturnValue1 As Long, ByRef sReturnValue2 As String) As Boolean
  ' Bla bla
End Function

---

Quote:

---

Originally Posted by Arnoutdv

Hmmm.
I often use the following construct in VB6

Code:

---

Public Function myFunction(lInput As Long, sInput As Long, ByRef lReturnValue1 As Long, ByRef sReturnValue2 As String) As Boolean
  ' Bla bla
End Function

---

---

I use that too.
It's basically the way the C-WinApi is designed: return the result in a Reference, and the function-result is some kind of error-code.

Arnout, for clarity's sake: Your first two arguments should be ByVal! (Not implicit ByRef as it's now)

I know, if you don't specify ByVal or ByRef the default is ByRef :-)

I don't see the value of the comma separator. Seems more likely to cause confusion than anything else.

Still, if you want to load every kind of construct you can come up with into a language, why not just use C#?

twinBASIC update:

https://nolongerset.com/twinbasic-up...ember-12-2021/

Highlights include VS Code Extensibility, RGB extraction functions, dropping Finalize(), and a discussion regarding potential typedef support.

Quote:

---

Originally Posted by VB6 Programming

twinBASIC update:

https://nolongerset.com/twinbasic-up...ember-12-2021/

Highlights include VS Code Extensibility, RGB extraction functions, dropping Finalize(), and a discussion regarding potential typedef support.

---

Nice update.

The conversation on typedef support was rather interesting. However, I think it's a bad idea, not because of any technical demerit but simply because I don't think this discussion takes into consideration undisciplined programmers. VB6 and BASIC in general tend to attract a lot of non-programmers that bring with them a serious lack of coding discipline. typedefs make it extremely easy to turn even the simplest programs into an unreadable mess. I really don't think something like this belongs in any BASIC language to be honest.

Quote:

---

Originally Posted by Niya

VB6 and BASIC in general tend to attract a lot of non-programmers that bring with them a serious lack of coding discipline.

---

I think that's a moot point today
I'd have thought that Python would have long since become the destination of choice for non-programmers looking to do a bit of coding.
And try dabbling in vb.net these days and you get very little assistance. All the microsoft examples are in c#.
In my brief experience it looks harder to find help for vb.net than vb6
What newbie is going to choose vb.net over c# in those circumstances?

Quote:

---

Originally Posted by vbrad

I think that's a moot point today
I'd have thought that Python would have long since become the destination of choice for non-programmers looking to do a bit of coding.
And try dabbling in vb.net these days and you get very little assistance. All the microsoft examples are in c#.
In my brief experience it looks harder to find help for vb.net than vb6
What newbie is going to choose vb.net over c# in those circumstances?

---

You might be right. Who knows. All I know is something as powerful typedef needs to be used responsibly. People who come from unforgiving programming backgrounds like C++ tend to be very respectful of it's power. Perhaps it might be good for TwinBASIC, I don't know. I'm not really leaning hard one way or another. It's just that my first instinct is that it doesn't belong in BASIC. I could be wrong. I guess we'll see what happens.

@Niya,
everything can be mis-used. The typedef is like a UDT, just shortcut like. (direct)

Quote:

---

Originally Posted by Niya

You might be right. Who knows. All I know is something as powerful typedef needs to be used responsibly. People who come from unforgiving programming backgrounds like C++ tend to be very respectful of it's power. Perhaps it might be good for TwinBASIC, I don't know. I'm not really leaning hard one way or another. It's just that my first instinct is that it doesn't belong in BASIC. I could be wrong. I guess we'll see what happens.

---

I'm of two minds about TypeDefs:
Reading C-Code it drives me up the walls trying to figure out, what's the "original" type.
Not knowing any better, i think TypeDefs in C were invented because C-Programmers are lazy buggers :-)

OTOH, the example on the page linked to above, defining SubSets of Types is intriguing, so a MyWindow=MyMenu shouldn't compile despite being the same base-type

Quote:

---

Originally Posted by Niya

It's just that my first instinct is that it doesn't belong in BASIC.

---

Like for example, "anonymous functions"? ;)

Olaf

Quote:

---

because C-Programmers are lazy buggers :-)

---

Quite right and c++ ones are worse! Why type begin when you can use { and end instead of } Why use int when you could use I or D instead of double. Typing just gets in the way of coding. Come to think of it, why not just use APL... :D :p

IMO, TypeDefs only make sense if you're supposed to code Cross-Platform and/or cross-bitness, to write your code only once.

along the lines of

Code:

---

#If Win64 Then
Public Type APointer As UInt64
#Else
Public Type APointer As UInt32
#End If

Public Function GetPointer As APointer
'Bla
End If

---

EDIT: And even this (conditional compilation) is subject to discussion, if this shouldn't be handled by the IDE, say, the chosen compile-target

Quote:

---

Originally Posted by Krool

@Niya,
everything can be mis-used. The typedef is like a UDT, just shortcut like. (direct)

---

Like I said, it was just my instinct. The issue of whether typedefs should be included in a BASIC language is not one I'm prepared to go to war over. I'm fine with them being included. They are powerful and when used right can really improve productivity. But it's just so scary to think about how easily they can be abused to create an unreadable mess.

Quote:

---

Originally Posted by Schmidt

Like for example, "anonymous functions"? ;)

Olaf

---

A script kiddie just learning the power of programming could do a lot more damage with typedefs than anonymous functions. :D

Quote:

---

Originally Posted by Zvoni

i think TypeDefs in C were invented because C-Programmers are lazy buggers :-)

---

Errr...not so fast. They are a great feature when used with discipline. I've grown to appreciate them over the years because of it's usage in the Win32 API. They can make things a lot easier to understand when used properly.

For example, take HWND and HBITMAP. Both these things are nothing more than a HANDLE typedef which in turn is a typedef for a void pointer(void*) . This means that both HWND and HBITMAP are just ordinary pointers. But when you encounter HWND while reading a piece of code, you immediately know what is expected, in this case, a handle to a window. Without typedefs, you would have void* all over the place and you could never be sure if a certain function expects a handle to a window or a bitmap. Typedefs can help make it much easier reason about what a piece of code is doing because of the extra information it provides to the one reading the code. Without typedefs, the only other way to do this would be to use classes and structures which are both good options but sometimes it's overkill. Typedefs allow you a way to create new types without actually creating new types which is an incredibly efficient way of solving this problem.

The thing is, it's extremely easy to abuse and if one is not careful, it can make code thoroughly unreadable. It could very well be the most destructive feature ever conceived in the world of programming when used improperly. It requires incredible discipline to use this effectively in a large codebase. The Microsoft guys are very disciplined and still, it sometimes feel like a chore trying to decipher typedefs in their C++ header files. Typedefs are not a feature to treat lightly.

Quote:

---

Originally Posted by Niya

Errr...not so fast. They are a great feature when used with discipline. I've grown to appreciate them over the years because of it's usage in the Win32 API. They can make things a lot easier to understand when used properly.

For example, take HWND and HBITMAP. Both these things are nothing more than a HANDLE typedef which in turn is a typedef for a void pointer(void*) . This means that both HWND and HBITMAP are just ordinary pointers. But when you encounter HWND while reading a piece of code, you immediately know what is expected, in this case, a handle to a window. Without typedefs, you would have void* all over the place and you could never be sure if a certain function expects a handle to a window or a bitmap. Typedefs can help make it much easier reason about what a piece of code is doing because of the extra information it provides to the one reading the code. Without typedefs, the only other way to do this would be to use classes and structures which are both good options but sometimes it's overkill. Typedefs allow you a way to create new types without actually creating new types which is an incredibly efficient way of solving this problem.

The thing is, it's extremely easy to abuse and if one is not careful, it can make code thoroughly unreadable. It could very well be the most destructive features ever conceived in the world of programming when used improperly. It requires incredible discipline to use this effectively in a large codebase. The Microsoft guys are very disciplined and still, it sometimes feel like a chore trying to decipher typedefs in their C++ header files. Typedefs are not a feature to treat lightly.

---

Hmm, OK, agreed. Haven't looked at it from that POV, since i've never programmed a single line in C or C++.
And you're probably right with discipline at Microsoft.
But since i'm reading (!!) a lot of C-Code (No MS-Code --> writing bindings for custom c-lib in Pascal), it just annoys the hell out of me, when i have to ask "is that an Integer, an unsigned Integer or what?"
And let's not talk about hungarian notation ad nauseum

Yes, everything in life works effectively, if you apply discipline to it.
I'm a skydiver. With no discipline i'd just burn a whole into the sky, and be a danger to me and others
Christiano Ronaldo became the best footballer of the world with what? Correct, discipline.

The problem is, that a lot of people try to use shortcuts, and leave a mess behind.

Yep. That's pretty much it.

Quote:

---

Originally Posted by Zvoni

Haven't looked at it from that POV, since i've never programmed a single line in C or C++.

---

You can benefit from it without having to use C/C++ if you ever use Win32 extensively. The most common examples you'd encounter is API functions that take strings. When you see LPWSTR, you immediately know you're expected to pass a pointer to a UTF-16 string. If you see LPSTR, you know immediately that an ANSI string is expected and if you see LPTSTR, you know that the expected string is ANSI if you're on any Windows pre-XP and UTF-16 on any NT based Windows. All of these typedefs boil down to a char*. If this were used instead, all you would know is that a pointer to a character array is expected. Unless explicitly written somewhere, you'd never know what kind of character array is expected.

Quote:

---

Originally Posted by vbrad

I think that's a moot point today
I'd have thought that Python would have long since become the destination of choice for non-programmers looking to do a bit of coding.
And try dabbling in vb.net these days and you get very little assistance. All the microsoft examples are in c#.
In my brief experience it looks harder to find help for vb.net than vb6
What newbie is going to choose vb.net over c# in those circumstances?

---

That may just be you, actually. For some reason, I tend to find VB.NET examples even when looking for C#. MS tends to put out both, often on tabbed pages, but I wonder if Google doesn't have a hand in the search results you and I are getting?

Here's a thing I got reminded of when I came across this thread. Asynchronous methods. Has there been any discussion about whether asynchronous methods will be implemented in TwinBASIC?

Not only do they exist in .Net(VB and C#), they are also implemented in many languages including Python and JavaScript. Async/Await has become quite a popular paradigm over the last decade and I think their inclusion in TwinBASIC is a very important discussion to be had. And they can be included without breaking compatibility with VB6 in any way.

Quote:

---

Originally Posted by Niya

Here's a thing I got reminded of when I came across this thread. Asynchronous methods. Has there been any discussion about whether asynchronous methods will be implemented in TwinBASIC?

Not only do they exist in .Net(VB and C#), they are also implemented in many languages including Python and JavaScript. Async/Await has become quite a popular paradigm over the last decade and I think their inclusion in TwinBASIC is a very important discussion to be had. And they can be included without breaking compatibility with VB6 in any way.

---

Yes there is a open issue in GitHub for that.
https://github.com/WaynePhillipsEA/twinbasic/issues/173

Quote:

---

Originally Posted by Shaggy Hiker

That may just be you, actually. For some reason, I tend to find VB.NET examples even when looking for C#. MS tends to put out both, often on tabbed pages, but I wonder if Google doesn't have a hand in the search results you and I are getting?

---

That could well be it because I never look for vb.net stuffn normally. But i have been playing around with it a bit recently
making great progress NOT!

As an example, the following shell command works in vb6 but not in vb.net and I've no idea why

Code:

---

        Dim s As String
        s = """C:\Program Files (x86)\Microsoft Visual Studio\VB98\VB6.EXE"" ""C:\test folder\Project1.Vbp"""

        'VB.NET (2008)
        Shell(s, AppWinStyle.MaximizedFocus) 'System.IO.FileNotFoundException was unhandled
       
        'VB6
        Shell s, vbMaximizedFocus  'works

---

Quote:

---

Originally Posted by vbrad

That could well be it because I never look for vb.net stuffn normally. But i have been playing around with it a bit recently
making great progress NOT!

As an example, the following shell command works in vb6 but not in vb.net and I've no idea why

Code:

---

        Dim s As String
        s = """C:\Program Files (x86)\Microsoft Visual Studio\VB98\VB6.EXE"" ""C:\test folder\Project1.Vbp"""

        'VB.NET (2008)
        Shell(s, AppWinStyle.MaximizedFocus) 'System.IO.FileNotFoundException was unhandled
       
        'VB6
        Shell s, vbMaximizedFocus  'works

---

---

Does the exception have any detail in it's error message or inner exception as to which file wasn't found?

Also. Net has the Process class amongst others to make launching external applications a lot easier.

Quote:

---

Originally Posted by PlausiblyDamp

Does the exception have any detail in it's error message or inner exception as to which file wasn't found?

Also. Net has the Process class amongst others to make launching external applications a lot easier.

---

Hi PD, thanks for your interest.
The "inner exception:" was empty and no mention of a file name that i could see, (both are present).
The following strings with no arguments also failed with the same exception and with no inner exception text, if that suggests anything.

Code:

---

s = "C:\Program Files (x86)\Microsoft Visual Studio\VB98\VB6.EXE"
        s = """C:\Program Files (x86)\Microsoft Visual Studio\VB98\VB6.EXE"""
        Shell(s, AppWinStyle.MaximizedFocus)

---

I think I got Process.start() to work at some point but it simply ignored the Command string argument, ie it just opened VB6 with no project selected.

Maybe it's a vb2008 thing?

Those old VB6 style things like Shell was provided to make VB6 programmers feel more comfortable with .Net but makes no mistake, doing things that way is strongly discouraged in VB.Net. I'm not surprised that fails for some unknown reason. Process.Start is the way to go.

Quote:

---

Originally Posted by Krool

Yes there is a open issue in GitHub for that.
https://github.com/WaynePhillipsEA/twinbasic/issues/173

---

Ah ok.

So...now this thread has wandered into VB.NET???

Quote:

---

Originally Posted by Shaggy Hiker

So...now this thread has wandered into VB.NET???

---

A lot of TwinBASIC features, both suggested and implemented, are inspired by VB.Net. Generics even use the exact same syntax.

Quote:

---

Originally Posted by Niya

Those old VB6 style things like Shell was provided to make VB6 programmers feel more comfortable with .Net but makes no mistake, doing things that way is strongly discouraged in VB.Net. I'm not surprised that fails for some unknown reason. Process.Start is the way to go.

---

Yes but pasting "C:\Program Files (x86)\Microsoft Visual Studio\VB98\VB6.EXE" "C:\test folder\Project1.Vbp" into cmd.exe, works too!
So VB6 and the Windows 10 command line work but vb.net fails?

EDIT:
Process.Start worked in both the following formats:

Code:

---

Process.Start("""C:\Program Files (x86)\Microsoft Visual Studio\VB98\VB6.EXE""", """C:\test folder\Project1.Vbp""")
'and
Process.Start("C:\Program Files (x86)\Microsoft Visual Studio\VB98\VB6.EXE", """C:\test folder\Project1.Vbp""")

---

It failed if I did not wrap the arguments parameter in double quotes because of the space in the address.
It worked with or without the extra double quotes in the firat parameter.

Anyway I'll leave it there, sorry for sidetracking the conversation.

To be honest, I couldn't tell you why that fails because in my opinion it would just be a waste of time trying to figure out why since using the Process class is the way to go. When I first moved to VB.Net from VB6, I only used those old VB6 things for like a week or two before I learned to do things the .Net way. There are probably all kinds of bugs and quirks in this old VB6 compatibility namespace.

Quote:

---

Originally Posted by Niya

To be honest, I couldn't tell you why that fails because in my opinion it would just be a waste of time trying to figure out why since using the Process class is the way to go. When I first moved to VB.Net from VB6, I only used those old VB6 things for like a week or two before I learned to do things the .Net way. There are probably all kinds of bugs and quirks in this old VB6 compatibility namespace.

---

Actually I don't know that it is a member of the VB6 compatibility namespace. I think it's part of core vb.net if that makes sense and looking at the intellisense just now (sorry!) it doesn't mention accepting arguments in its path whereas the target path in the vb6 function can include arguments.

Quote:

---

Originally Posted by vbrad

Actually I don't know that it is a member of the VB6 compatibility namespace.

---

It's fully qualified name is Microsoft.VisualBasic.Interaction.Shell(). The Microsoft.VisualBasic namespace is provided for compatibility with VB6. You will find all of the VB6 stuff in that namespace and it's use is not recommended for development. It was only provided to make migration of code from VB6 to VB.Net less of a chore, though it failed in this regard since the differences between VB6 and VB.Net goes far beyond what is contained in that namespace alone.

twinBASIC status update:

https://nolongerset.com/twinbasic-up...ember-19-2021/

Highlights include discussions around block scoping and a planned ObjRefCount() function.

Quote:

---

Originally Posted by Niya

It's fully qualified name is Microsoft.VisualBasic.Interaction.Shell(). The Microsoft.VisualBasic namespace is provided for compatibility with VB6. You will find all of the VB6 stuff in that namespace and it's use is not recommended for development. It was only provided to make migration of code from VB6 to VB.Net less of a chore, though it failed in this regard since the differences between VB6 and VB.Net goes far beyond what is contained in that namespace alone.

---

Thanks Niya, I stand corrected (The reason why I'd thought it might not have been was because I hadn't put in any import statements but it had still worked).

Quote:

---

Originally Posted by vbrad

(The reason why I'd thought it might not have been was because I hadn't put in any import statements but it had still worked).

---

Well remember, Microsoft wanted VB6 developers to use VB.Net instead so the extra hassle of having to import it might have been off-putting which is why it is imported by default. They wanted to make the transition as easy as possible. It worked in my case. It made it very easy for me to transition from VB6 to VB.Net and gave me something to rely on until I learned how to do things "the .Net way".