TwinBasic

Quote:

---

Originally Posted by mansellan

"Better" is always subjective. Is VB.Net, the language "better" than VB6? It depends... VB.Net - the language - is objectively more advanced. It has a unified type system, generics, overloads, delegates. But it's also further away from the metal. There's a VM in the mix, complete with generational garbage collection. For any given use-case, perhaps that's the best fit, perhaps not.

VB6 is "better" in that it compiles to native Win32. No massive framework to depend on or tow around. Simple, deterministic memory management. It can do inline assembly.

This is why I love (and bought into) the concept of twinBASIC - modern source constructs but native code. It's something that .Net (despite several attempts) hasn't ever achieved. It might be better*

*No such thing.

---

When I say VB6, I'm talking about about language, IDE and the runtime.

Anyways, I could go in on this but I've already done so many times before so I'm not going to prolong this discussion and derail this thread any further. This is not an attack on you or anything by the way. It's just that I think I've said all I had to say on the topic over the years. There is very little I could say now that would be new information. Everyone should use what they like but what someone likes doesn't change facts. That's all I'm saying. There are tools, frameworks and languages that I think are better in a lot of regards than Microsoft's .Net tools and I have no problem admitting that I'm using an inferior tool. For example, I think Flutter might be a far better platform for creating Android applications than Xamarin/C# but I will still use Xamarin. I just prefer to use it for now since I'm far more familiar with the tech, not because I think it's better. But if I intend to go into Android development seriously, I will use the best tool for the job. None of this is emotional for me. There is no loyalty with me when it comes what tools to use. I used to be like that but as I got older I realized that it is foolish to be too attached to specific tools just because you love them.

I think over the years, I just became a lot more objective about evaluating things like this. Most people can't be that objective which I think is the source of all the contention here.

Quote:

---

Originally Posted by vbrad

What if "Other Basic" was moved from "Other languages" to just under "VB6 and earlier".
Even without all the current interest in TwinBasic and Radbasic, it might be a more appropriate location for it anyway
The subforum currently occupying that spot hasn't had a post since last October. Does it deserve to still be "above the fold"?

---

That's a good idea. Please repost this suggestion in the Forum Feedback.

Quote:

---

Originally Posted by Niya

For example, I think Flutter might be a far better platform for creating Android applications than Xamarin/C# but I will still use Xamarin. I just prefer to use it for now since I'm far more familiar with the tech, not because I think it's better. But if I intend to go into Android development seriously, I will use the best tool for the job.

---

Perfectly said. I also personally believe that we need to use the best tool available for a task in the market. In my case I prefer using B4A instead of any other mobile development tools when it comes to developing apps for Android platform.

I will just narrate a small incidence. A few years back we started developing a product called AlbumSense (now split into two products AlbumSense and PhotoSense) for a client in VB6. We studied PhotoDemon's code and borrowed quite a lot from it, but as we progressed in our development we started running into problems especially performance related problems in image processing.

So after spending around 4 months on development in VB6. But we had to ditch it and switch to Delphi as it has all the things (read components) that we want. And it was finalized that we want to give one single executable of the software instead of shipping a plethora of supporting libraries (DLLs), etc. with it.

We completed the product development in record time and our client is selling it like hot cakes for a while now.

During the phase when we switched from VB6 to Delphi we had a lot of problem finding assistant codes who knew Pascal. And it was as this time that we got the idea of creating a development tool that will have a huge library of components/controls (over time) and that would allow one to program in multiple languages in the same project and thus was born MixLangz.

Quote:

---

Originally Posted by Shaggy Hiker

That's a good idea. Please repost this suggestion in the Forum Feedback.

---

Thanks Shaggy Hiker, I'm glad that you agree! I'll do that right away!

Quote:

---

Originally Posted by IndicSoftware

So after spending around 4 months on development in VB6. But we had to ditch it and switch to Delphi as it has all the things (read components) that we want. And it was finalized that we want to give one single executable of the software instead of shipping a plethora of supporting libraries (DLLs), etc. with it.

---

Well there you go. :)

Way back when, I preferred Delphi over c/c++ as at the time I was a Pascal 'expert' - and it did have all those components. I also preferred Borland c/c++ over Microsoft - until I was forced to use Microsoft... Borland is now Embarcadero but their c++ compilers still have all those components. Pity they don't do a free 'Community' version - just a trial version.

Removed...

For Christ's sake blokes. Can you not keep a thread on track? You are honestly all on your own agendas here and each seems to be focussed on solely attempting to win a spurious and pointless argument or poking others to respond.

We know how you feel already. Honestly, can you please let it go and let TwinBasic be the point of discussion on a TwinBasic thread?

See my signature and add your own name to that list and let's move on!

Quote:

---

Originally Posted by yereverluvinuncleber

For Christ's sake blokes. Can you not keep a thread on track? You are honestly all on your own agendas here and each seems to be focussed on solely attempting to win a spurious and pointless argument or poking others to respond.

We know how you feel already. Honestly, can you please let it go and let TwinBasic be the point of discussion on a TwinBasic thread?

See my signature and add your own name to that list and let's move on!

---

I'm from an authoritarian country and I'm trying to experience the taste of democracy. ;)

Free speech doesn’t mean you have to say everything you think.

Quote:

---

Originally Posted by TTn

[*]Intellisense does not initiate parameter/return types after typing spacebar (accepts only tab for some reason).

---

Just to let you know, the spacebar should now be confirming the intellisense option as of v0.10.4966 of tB.

twinBASIC status update:

https://nolongerset.com/twinbasic-up...ugust-22-2021/

Quote:

---

Originally Posted by WaynePhillipsEA

Just to let you know, the spacebar should now be confirming the intellisense option as of v0.10.4966 of tB.

---

Wow thanks, that was quick! I will take a look tonight to see the progress, I'm working out installer kinks at the moment with msm files.

Things are going better than I hoped on both projects. Thank you for keeping VB6 compatibility a high priority.

Quote:

---

Originally Posted by WaynePhillipsEA

... should now be confirming the intellisense option as of v0.10.4966 of tB.

---

Yes, it does confirm the selected intellisense. Except, it does not auto-select the closest match. I have to use arrow keys to select, then type spacebar.

In VB6 i can type the letters:

Code:

---

If me.wi {spacebar}

---

We get Me.Width.
The word is autocompleted very fast and fluidly. This is important for the flow of human writing, especially when the words are longer.
Still, this is a big improvement for tB. Good work getting that sorted.

If you're still around Wayne I wanted to make another minor suggestion. String interpolation. Here's an example of how it works in VB.Net:-

Code:

---

        Dim name As String = "Kathy"
        Dim age As Integer = 14
        Dim address As String = "121 Pine Street"

        Debug.WriteLine($"{name} is {CStr(age)} years old. She lives at {address}.")

---

Output:-

Code:

---

Kathy is 14 years old. She lives at 121 Pine Street.

---

This feature is such a huge help when dealing with Strings in VB.Net. It would be nice if TwinBASIC had something like this if it doesn't already.

Quote:

---

Originally Posted by 2kaud

Way back when, I preferred Delphi over c/c++ as at the time I was a Pascal 'expert' - and it did have all those components. I also preferred Borland c/c++ over Microsoft - until I was forced to use Microsoft... Borland is now Embarcadero but their c++ compilers still have all those components. Pity they don't do a free 'Community' version - just a trial version.

---

Currently there is a community version of C++ Builder available. Please have a look at this.

Quote:

---

https://www.embarcadero.com/products/cbuilder/starter

---

Quote:

---

Originally Posted by Niya

If you're still around Wayne I wanted to make another minor suggestion. String interpolation. Here's an example of how it works in VB.Net:-

Code:

---

        Dim name As String = "Kathy"
        Dim age As Integer = 14
        Dim address As String = "121 Pine Street"

        Debug.WriteLine($"{name} is {CStr(age)} years old. She lives at {address}.")

---

Output:-

Code:

---

Kathy is 14 years old. She lives at 121 Pine Street.

---

This feature is such a huge help when dealing with Strings in VB.Net. It would be nice if TwinBASIC had something like this if it doesn't already.

---

Thanks Niya. Yes, string interpolation has been discussed and is planned, see https://github.com/WaynePhillipsEA/twinbasic/issues/132

Quote:

---

Originally Posted by Episcopal

I may be wrong, but apparently the twinbasic goes further ...

---

I agree

Quote:

---

Originally Posted by Shaggy Hiker

You don't speak American English. The proper phrase, and one which you do hear a LOT in the US, would be, "Ain't there no coffee in that cup?" If you turn the slang "ain't" into proper English, that sentence becomes: "Is not there no coffee in that cup?"

I would suggest, therefore, that "Ain't there no coffee in that cup?" is at least as bad as what you say you never hear, but it's in common usage. It's called a double negative. Peopled use them without thinking about the actual meaning, and they are quite common. Whether they use them as double negatives or not doesn't even matter. Speech is what we use it to be.

---

Nobody doesn't like Sara Lee.

twinBASIC status update:

https://nolongerset.com/twinbasic-up...ugust-29-2021/

Highlights include Unit Testing support, conditional breakpoints, the Nz() function, and various IntelliSense improvements.

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".