-
Aug 9th, 2021, 06:00 AM
#241
Re: TwinBasic
Originally Posted by Niya
I just gave TwinBasic an actual try and HOLY **** IM IMPRESSED!!!
Now, it's very far from being a production ready version of VB6 but for all the talk I've heard over the years about a new VB6 IDE, this one is really for real. I mean I believed in it's promise ever since I first heard of it here on these forums but I had no idea how advanced it really was already. I just took some semi-complex code I wrote in this post and popped it in, expecting a problem or two but the damn thing just worked, without needing a single change. This is really good progress, especially on the promise on VB6 compatibility.
Looks like you guys are getting your new VB6 after all. You guys have been waiting decades for this. Don't let this fail now.
Now, there are a couple pain points that I think may need to be worked out but I'll do that in a follow up post. Gonna play with for a little bit and see what comes up.
Twice in one day I've agreed with something you've posted. One of us must not be well
-
Aug 9th, 2021, 08:03 AM
#242
Re: TwinBasic
Originally Posted by VB6 Programming
Twice in one day I've agreed with something you've posted. One of us must not be well
I've never had any problems with people liking or wanting to use VB6. I'm really glad it's die hard fans are finally getting what they wanted for all these years. I'm really happy for you guys. My problem was always with all of the misinformation that came out of the VB6 camp about .Net. and all of the emotionally driven drivel that came with that misinformation campaign.
I have no problem with VB6 but VB.Net really is a great successor that brought a lot of things that I and a lot of people always wanted. However, that came at the cost of compatibility with VB6 and yes, that was a bad thing. It was a terrible thing Microsoft did to VB6 developers when they abandoned VB6 but I fully understand why they did it. When I looked at what .Net has become today, I see now why they couldn't use VB6 as a base. It just would not have worked, at least not without 10x the effort.
Anyways, TwinBASIC really is impressive and based on what I've seen so far, it has a very bright future. Hopefully, the developers won't get burned out before it reaches it's full potential and when it's production ready, I'd have no problem recommending it to anyone. In fact, I'd go so far as to recommend it over VB.Net for beginners looking to get into Windows programming. One of the very few things VB6 does better than any .Net language is that it is far more approachable as a development platform. You can get along in VB6 without knowing anything about classes, inheritance, delegates, generics, lambda expressions, async/await etc. Don't get me wrong, these features do bring a lot of power to a language but beginners, hobbyists and people looking to do something simple will be overwhelmed and you can't really get away from most of this in .Net. You certainly can write code without it but eventually you will need to Google something and you are going to run into these things and as a beginner, it will be very scary. VB6 tends to keep things simple.
That is not to say that TwinBASIC cannot benefit from some modern features. For example, declaring and initializing a variable on the same line:-
No matter how simple a language is, there's no excuse to not have this ability. Of course the biggest modern benefit by far that TwinBASIC will have is a powerful modern IDE behind it which makes a huge difference. A modern IDE alone is enough for me to take it seriously.
So yea, this is a really good thing for everyone and I'm genuinely happy for all find satisfaction in having this choice.
-
Aug 9th, 2021, 08:08 AM
#243
Re: TwinBasic
Originally Posted by Niya
Couple of pain points in the intellisense. It doesn't work with enum type parameters. You actually need to type out the enum type with the dot for the enum choices to come up.
Also it's really hard to get a sense of what is what when reading the intellisense description of functions and subs. Visual Studio uses different colours/text styles so you can easily differentiate parameter names, function/sub name and parameter types. Sometimes I just want to know what the parameters are at a glance and having different colours represent different things goes a very very long way. It doesn't even have to be colours alone. Simply bolding or using italics can help. The VB6 intellisense bolds function/sub parameters you're currently typing so you can tell at a glance what you're looking it and where you are.
I know these seem minor but they are huge productivity boosts.
EDIT:
Just noticed the intellisense underlines the parameter you're currently typing. It's not noticeable enough. Maybe bold it too or perhaps use a different colour like modern versions of Visual Studio does.
Thanks Niya! Glad you're liking it.
For the enum parameters intellisense, I've opened an issue in our GitHub tracker here: https://github.com/WaynePhillipsEA/twinbasic/issues/337
For the signature-help formatting, unfortunately VS Code doesn't offer customization here. The active parameter should be both bold and underlined, but I do agree that it's not always particularly clear. Hopefully VS Code will improve their offering for this in the future, but for now we can only provide plaintext for the signature help text, and VS code applies its bold+underline formatting to the active parameter part based on offsets into the plaintext data provided by the language server.
Thanks again for looking at twinBASIC, and for your valuable feedback, all noted.
-
Aug 9th, 2021, 09:12 AM
#244
Re: TwinBasic
Originally Posted by WaynePhillipsEA
Thanks Niya! Glad you're liking it.
I'll always be a .Net guy but I really love seeing good work like this and we do have some legacy VB6 stuff that needs maintaining. TwinBASIC would be a good fit.
Originally Posted by WaynePhillipsEA
Nice. That is the issue exactly. I was actually thinking about coming back around to provide a picture myself just in case I wasn't clear enough but you got it.
Originally Posted by WaynePhillipsEA
For the signature-help formatting, unfortunately VS Code doesn't offer customization here. The active parameter should be both bold and underlined, but I do agree that it's not always particularly clear. Hopefully VS Code will improve their offering for this in the future, but for now we can only provide plaintext for the signature help text, and VS code applies its bold+underline formatting to the active parameter part based on offsets into the plaintext data provided by the language server.
Ah ok. This also brings me to something else. Did you guys ever consider integration with Visual Studio itself. One other minor pain point I had was how different VS Code is to Visual Studio. I kept trying to do things the "Visual Studio" way. I mean it's not essential, as VS Code isn't that hard use but it really bites when you're so much more familiar with something else. It would be really great if it was integrated into Visual Studio itself. That could also go a long way as well. Visual Studio is really popular on Windows amongst Windows programmers so it would be a big deal if Visual Studio was also available as a choice alongside VS Code.
Originally Posted by WaynePhillipsEA
Thanks again for looking at twinBASIC, and for your valuable feedback, all noted.
No problem. Really great work. Keep it up!
-
Aug 9th, 2021, 11:38 AM
#245
Member
Re: TwinBasic
Originally Posted by Niya
Ah ok. This also brings me to something else. Did you guys ever consider integration with Visual Studio itself. One other minor pain point I had was how different VS Code is to Visual Studio. I kept trying to do things the "Visual Studio" way. I mean it's not essential, as VS Code isn't that hard use but it really bites when you're so much more familiar with something else. It would be really great if it was integrated into Visual Studio itself. That could also go a long way as well. Visual Studio is really popular on Windows amongst Windows programmers so it would be a big deal if Visual Studio was also available as a choice alongside VS Code.
twinBASIC connects to VS Code using standard protocols (LSP and DAP), so it should be possible to integrate with Visual Studio, or any other IDE that implements the protocols. I opened an issue on the GitHub tracker to propose this: https://github.com/WaynePhillipsEA/twinbasic/issues/82. The only slight complication is that VS Code uses a virtual filesystem, but I'm sure that can be worked around.
That said, I suspect it's not a priority right now - VS Code is a good fit as it's cross-platform. And the language needs a "primary" IDE for support reasons. Potentially other integrations could be written by the community.
Note, I'm just an interested party, not a tB developer.
-
Aug 9th, 2021, 12:14 PM
#246
Re: TwinBasic
Originally Posted by Niya
I'll always be a .Net guy but I really love seeing good work like this and we do have some legacy VB6 stuff that needs maintaining. TwinBASIC would be a good fit.
Nice. That is the issue exactly. I was actually thinking about coming back around to provide a picture myself just in case I wasn't clear enough but you got it.
Ah ok. This also brings me to something else. Did you guys ever consider integration with Visual Studio itself. One other minor pain point I had was how different VS Code is to Visual Studio. I kept trying to do things the "Visual Studio" way. I mean it's not essential, as VS Code isn't that hard use but it really bites when you're so much more familiar with something else. It would be really great if it was integrated into Visual Studio itself. That could also go a long way as well. Visual Studio is really popular on Windows amongst Windows programmers so it would be a big deal if Visual Studio was also available as a choice alongside VS Code.
No problem. Really great work. Keep it up!
Integration with VS was considered, yes. From the start of the project I felt that one of the most important thing was to extend an existing IDE rather than creating one from scratch, and it was just a case of having to choose one. After much research, VS Code seemed to be way ahead of every other option in terms of supporting open-protocols; LSP for the language and DAP for debugging. VS does now offer support for LSP and DAP protocols, but from what I've seen it's nowhere near as feature complete as what is offered by VS Code. Additionally the VS Code API is actually really nice to work with - it is clear the team have put extension authors at the heart of everything VS Code offers.
As @mansellan rightly points out, by using these modern open-protocols (LSP+DAP), it would actually be fairly easy to switch to another IDE at some later point (provided enough of the protocols features are implemented). For support reasons, our current official view is that VS Code is the twinBASIC IDE. If others in the community were to make twinBASIC work with other editors, I would absolutely support their efforts as best as I can.
All that said, I am very aware that there are improvements still needed to help make the transition from VB6 to twinBASIC/VS Code, so expect further improvements in due course as we put more effort into that.
-
Aug 9th, 2021, 01:21 PM
#247
Re: TwinBasic
@mansellan
@WaynePhillipsEA
Ok that's fine. VS Code is not a bad IDE. It's just different and seems far more generalized. Every version of Microsoft's IDEs have done certain things the same way since QuickBasic. for example F9 being used to set break points and F8 for single stepping and dozens of other tiny things. At least you guys preserved some of these conventions in VS Code.
-
Aug 11th, 2021, 12:20 PM
#248
Re: TwinBasic
Originally Posted by Niya
Couple of pain points in the intellisense. It doesn't work with enum type parameters. You actually need to type out the enum type with the dot for the enum choices to come up.
@Niya, just to let you know, this should now be working as of v0.10.4125 ( https://github.com/WaynePhillipsEA/twinbasic/issues/337 ). Thanks for your feedback!
-
Aug 11th, 2021, 05:28 PM
#249
Re: TwinBasic
Originally Posted by WaynePhillipsEA
Nice. Good work.
-
Aug 13th, 2021, 03:05 AM
#250
Re: TwinBasic
Just found a breaking bug in v0.10.4198
Code:
Public Type TESTTYPE
testString As string * 13 * 2
End Type
The above module level code crashes the compiler.
-
Aug 13th, 2021, 05:19 AM
#251
Re: TwinBasic
Another minor bug, Go to Definition doesn't seem to work with constants that are in another module in another .twin file.
-
Aug 13th, 2021, 05:29 AM
#252
Re: TwinBasic
Originally Posted by Niya
Just found a breaking bug in v0.10.4198
Code:
Public Type TESTTYPE
testString As string * 13 * 2
End Type
The above module level code crashes the compiler.
Thanks Niya! I created an issue for it over on GitHub:
https://github.com/WaynePhillipsEA/twinbasic/issues/350
And it's now fixed in v0.10.4273.
-
Aug 13th, 2021, 05:31 AM
#253
Re: TwinBasic
Originally Posted by Niya
Another minor bug, Go to Definition doesn't seem to work with constants that are in another module in another .twin file.
Issue for tracking : https://github.com/WaynePhillipsEA/twinbasic/issues/351
Thanks!
-
Aug 13th, 2021, 06:45 AM
#254
Re: TwinBasic
Wow. You guys work fast. Nice job.
I spent the last 3 days testing out TwinBASIC by taking on something with a more teeth than just printing simple stuff with MsgBox. I decided to really test it by writing a GUI application using pure Win32 from scratch(no copy and pasting code from anywhere) and purely using Visual Studio Code to get a feel for the debugging experience. I just finished it and released it here if anyone wants to check it out.
I have to say, it is really impressive how capable TwinBASIC is, even at this time with bugs and issues popping up here and there. Even though it's still very far from it's goal of VB6 compatibility, it felt like a complete product in it's own right. I had very little trouble coding against the Win32 API and I felt as if I could do anything I wanted. In this regard it is EVERY BIT as capable as VB6.
That being said, I do want to address some major pain points with the debugging experience in Visual Studio Code. Now, the debugger is very solid but not very intuitive to use. The biggest issue I had the entire time was getting breakpoints to work. The biggest pain with that is that I can't just run the application from the Build button if I want Stop or breakpoints to work. I had to use the run feature the "run procedure under cursor" which required me to go back to Sub Main and put the cursor under it every time. This was unbelievably annoying to do. I want to be able to set a breakpoint and run the application from right where I am, like I've been doing since QuickBasic.
Another very important thing that I really missed was the ability to put Debug.Print in my code to spit out data about the state of my application at runtime. Not having this ability slowed me down massively, especially when combined with what I said above about getting breakpoints to work.
There were a lot of other minor issues that I can't recall right now but those were my biggest problems.
Anyways, my overall experience with TwinBASIC was good. I was really impressed and I had a lot of fun testing this out. I'd like to continue but I have already spent 3 days on this and I need to get back to my work. Keep it up guys. TwinBASIC has real promise.
-
Aug 13th, 2021, 12:34 PM
#255
Re: TwinBasic
Originally Posted by Niya
Wow. You guys work fast. Nice job.
I spent the last 3 days testing out TwinBASIC by taking on something with a more teeth than just printing simple stuff with MsgBox. I decided to really test it by writing a GUI application using pure Win32 from scratch(no copy and pasting code from anywhere) and purely using Visual Studio Code to get a feel for the debugging experience. I just finished it and released it here if anyone wants to check it out.
I have to say, it is really impressive how capable TwinBASIC is, even at this time with bugs and issues popping up here and there. Even though it's still very far from it's goal of VB6 compatibility, it felt like a complete product in it's own right. I had very little trouble coding against the Win32 API and I felt as if I could do anything I wanted. In this regard it is EVERY BIT as capable as VB6.
That being said, I do want to address some major pain points with the debugging experience in Visual Studio Code. Now, the debugger is very solid but not very intuitive to use. The biggest issue I had the entire time was getting breakpoints to work. The biggest pain with that is that I can't just run the application from the Build button if I want Stop or breakpoints to work. I had to use the run feature the "run procedure under cursor" which required me to go back to Sub Main and put the cursor under it every time. This was unbelievably annoying to do. I want to be able to set a breakpoint and run the application from right where I am, like I've been doing since QuickBasic.
Another very important thing that I really missed was the ability to put Debug.Print in my code to spit out data about the state of my application at runtime. Not having this ability slowed me down massively, especially when combined with what I said above about getting breakpoints to work.
There were a lot of other minor issues that I can't recall right now but those were my biggest problems.
Anyways, my overall experience with TwinBASIC was good. I was really impressed and I had a lot of fun testing this out. I'd like to continue but I have already spent 3 days on this and I need to get back to my work. Keep it up guys. TwinBASIC has real promise.
Niya... thanks so much for trying out twinBASIC! I'm very pleased that the overall experience was a good one, and thanks for your kind words.
I hear you about launching the debug session currently being awkward to start in Sub Main() -- I'll address that very soon. Breakpoints and Debug.Print etc should all be working provided you do run the code in the debugger rather than launching via the Build button, but I understand why you were using the Build button currently.
Thanks again - your feedback is invaluable.
-
Aug 13th, 2021, 03:02 PM
#256
Re: TwinBasic
@WaynePhillipsEA
Ok, did a little more testing and I want to bring a couple things to your attention. Hope I'm not annoying you with all this.
It seems pressing F5 works exactly the way it should and Breakpoint/Stop work the way I wanted when using it. I'm unsure if this was always working or if it's a recent fix since I haven't used F5 at all during those 3 days writing that application. But the reason I avoided using it was because I thought it wasn't working. Pressing F5 works but when you actually go to Run -> Start Debugging, it just gave me a menu thing to choose a debugger and when I chose twinbasic DEBUGGER, it didn't do anything. I should have been using F5 instead of the Build button all this time, but I didn't because the inconsistent behavior between Run -> Start Debugging and it's shortcut, F5 led me to believe this feature wasn't working. This is an example what what I meant when I said the debugger was unintuitive. A menu option and it's keyboard shortcut should do the same thing regardless of how you invoke it.
Also, using F5 to execute the program with the debugger still requires that you put the cursor in Sub Main which is a major pain point.
Also, I just tested Debug.Print with an F5 run and it works just as you said. However, Debug.Print doesn't show up in the intellisense which I why I assumed it didn't exist.
One last thing I just noticed about the debugger. It inherited a weakness from VB6 and it has to do with way it executes the program in debug mode. Now I'm making some assumptions here so feel free to correct me where I'm wrong, but I'm guessing that VB6 runs the program in the same process as the IDE which means anything that the program does in the process space would affect the IDE as well. I'm guessing it's one of the reasons why bad API calls can crash the VB6 IDE. It seems that TwinBASIC does something similar. Now, I haven't observed bad API calls crashing the Visual Studio Code IDE but I have noticed behaviors that lead me to believe that TwinBASIC programs run in the same address space as VS Code.
Modern versions of Visual Studio when running a program in debug mode actually run it as it's own process. This has a couple of advantages. For one, it lets you see debug the application with the exact behavior it would have when compiled and released in a production environment. Secondly and this is the more important point, it allows Windows to clean up resource leaks when your application terminates. If you are debugging an application in TwinBASIC and it breaks for any reason without cleaning up resources like GDI/User32/Kernel handles, these handles end up polluting the debugging session which can hamper the actual process of debugging the application.
You can test this leaking behavior with this code:-
Code:
Module MainModule
Private Declare Function CreateFileW Lib "kernel32" (ByVal lpFileName As Long, ByVal dwDesiredAccess As Long, ByVal dwShareMode As Long, ByVal lpSecurityAttributes As Long, ByVal dwCreationDisposition As Long, ByVal dwFlagsAndAttributes As Long, ByVal hTemplateFile As Long) As Long
Private Declare Function CloseHandle Lib "kernel32" (ByVal handle As Long) As Long
Private Const GENERIC_READ As Long = &H120089
Private Const NO_SHARE As Long = 0
Private Const OPEN_EXISTING As Long = 3
Private Const FILE_ATTRIBUTE_NORMAL As Long = &H80
Private Const INVALID_HANDLE_VALUE As Long = -1
' This project type is set to 'Standard EXE' in the Settings file, so you need a Main() subroutine to run when the EXE is started.
Public Sub Main()
Dim hfile As Long
Dim sFileName As String = "d:\t.txt"
hfile = CreateFileW(StrPtr(sFileName), GENERIC_READ, NO_SHARE, 0, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0)
If hfile = INVALID_HANDLE_VALUE Then
MsgBox ("Failed to open file")
Else
MsgBox("File open succeeded")
End If
'Comment this line out to see that consecutive F5 runs
'failed to open the file after the first run due to the file
'handle being leaked. Solving it requires that VS Code be completely restarted
'to allow Windows to close the handle.
CloseHandle(hfile)
End Sub
End Module
I've also tested this by leaking Timers and the results were unholy to say the least. Ended up with dozens of timers just running in the process causing all kinds of havoc.
-
Aug 13th, 2021, 03:40 PM
#257
Re: TwinBasic
Hey @Niya, sorry about the 'Start Debugging' menu thing... I am aware of it as someone else also mentioned it previously but haven't had chance to look deeper into it yet. I might open a separate issue for it so that it gets more prominent attention.
> Hope I'm not annoying you with all this
Not at all! It's great to get feedback. I'm way too close to the project to notice the little things that annoy new users, so I do take note of all feedback when it come in
Debug.Print not showing in the intellisense is also a known issue (https://github.com/WaynePhillipsEA/twinbasic/issues/269) and this will be addressed soon as I've been doing some work in this area so it makes sense to get that sorted now.
Indeed, the debugging session does run inside the same process as the compiler, and you're right that this does create some pain points, particularly with using the Win32 API. The debugger is tightly bound to the compiler at the moment, but it is planned to be separated out so that the debugged session can be run in a separate process. This change is not imminent, but will be done in the next few months. Thanks again!
-
Aug 13th, 2021, 04:12 PM
#258
Re: TwinBasic
Aite man. Keep up the good work!
-
Aug 13th, 2021, 04:45 PM
#259
Re: TwinBasic
Originally Posted by WaynePhillipsEA
Indeed, the debugging session does run inside the same process as the compiler, and you're right that this does create some pain points, particularly with using the Win32 API. The debugger is tightly bound to the compiler at the moment, but it is planned to be separated out so that the debugged session can be run in a separate process. This change is not imminent, but will be done in the next few months.
It just occurred to me that a nice stopgap measure would be some kind of button or shortcut that allows you to restart the IDE and reload the current project. If something like that were easy to implement, you could lean on that in the mean time until you're able to separate the compiler from the debugger.
-
Aug 13th, 2021, 07:32 PM
#260
Re: TwinBasic
Started experimenting with classes in TwinBASIC. Found two minor issues so far:-
- Intellisense doesn't work with Handles clause.
- Application crashes if you try to assign an object to an object variable without using Set:-
Code:
m_tc = New TestClass(900) 'Crashes
Code:
Set m_tc = New TestClass(900) 'Works
-
Aug 13th, 2021, 07:42 PM
#261
Re: TwinBasic
Also, would it be more helpful if I posted these on GitHub instead. Do you mind at all having to come over here at read these at VBForums? I'm just very familiar with posting here. I never did anything more than read/download stuff off GitHub.
-
Aug 13th, 2021, 07:56 PM
#262
Re: TwinBasic
Another thing I wanted to point about about TwinBASIC. I'm really loving the fact that the compiler can produce Windows executables with zero dependencies, an advantage it has over VB6 and .Net. .Net can't do it as far as I know(except when compiling for Linux) and VB6 does it very poorly(OCX errors, always having trouble finding DLLs etc). Although I will always veer towards using Visual Studio and .Net for any serious work, I could see myself using TwinBASIC to write very small and easy to deploy utility applications. I tend write a lot of little utilities in .Net, both for personal use and help wit h our work. And while I've never had serious problems with them, there is always that slight risk that something might be broken on somebody's computer and it would not run. Bare bones binaries coded against the Win32 API almost never fail to run on any Windows system. It would be nice if you guys could preserve this ability in future versions of TwinBASIC.
Last edited by Niya; Aug 13th, 2021 at 08:02 PM.
-
Aug 13th, 2021, 11:44 PM
#263
Re: TwinBasic
Originally Posted by Niya
Started experimenting with classes in TwinBASIC. Found two minor issues so far:-
- Intellisense doesn't work with Handles clause.
- Application crashes if you try to assign an object to an object variable without using Set:-
Code:
m_tc = New TestClass(900) 'Crashes
Code:
Set m_tc = New TestClass(900) 'Works
Could you provide a full example for this? My following attempt to reproduce generates a runtime unhandled error as expected, but not a hard crash:
Code:
Private Class TestClass
Sub New(aValue As Long)
End Sub
End Class
Module MainModule
Dim m_tc As Object
Sub Main()
m_tc = New TestClass(900)
End Sub
End Module
-
Aug 13th, 2021, 11:53 PM
#264
Re: TwinBasic
Originally Posted by Niya
Another thing I wanted to point about about TwinBASIC. I'm really loving the fact that the compiler can produce Windows executables with zero dependencies, an advantage it has over VB6 and .Net. .Net can't do it as far as I know(except when compiling for Linux) and VB6 does it very poorly(OCX errors, always having trouble finding DLLs etc). Although I will always veer towards using Visual Studio and .Net for any serious work, I could see myself using TwinBASIC to write very small and easy to deploy utility applications. I tend write a lot of little utilities in .Net, both for personal use and help wit h our work. And while I've never had serious problems with them, there is always that slight risk that something might be broken on somebody's computer and it would not run. Bare bones binaries coded against the Win32 API almost never fail to run on any Windows system. It would be nice if you guys could preserve this ability in future versions of TwinBASIC.
This feature will be staying Even once we've got GUI support, this feature is staying. Zero dependencies and small executables is one of the key benefits of twinBASIC.
-
Aug 13th, 2021, 11:55 PM
#265
Re: TwinBasic
Originally Posted by Niya
Also, would it be more helpful if I posted these on GitHub instead. Do you mind at all having to come over here at read these at VBForums? I'm just very familiar with posting here. I never did anything more than read/download stuff off GitHub.
It would be great to see you over at GitHub, and it helps so others can keep track of issues too. That said, if you prefer to stay over here, I'm fine with that also.
-
Aug 14th, 2021, 12:45 AM
#266
Re: TwinBasic
Originally Posted by WaynePhillipsEA
Could you provide a full example for this? My following attempt to reproduce generates a runtime unhandled error as expected, but not a hard crash:
My apologies, I should have chosen my works more carefully. That is what I meant, the program crashes with an exception.
With regards to this issue. I was under the impression that this would qualified as syntax error and not a runtime error which I why I found that exception odd. If not using Set was a violation, I was expecting the compiler to prohibit compilation of the code.
Originally Posted by WaynePhillipsEA
This feature will be staying Even once we've got GUI support, this feature is staying. Zero dependencies and small executables is one of the key benefits of twinBASIC.
This is good to hear.
Originally Posted by WaynePhillipsEA
It would be great to see you over at GitHub, and it helps so others can keep track of issues too. That said, if you prefer to stay over here, I'm fine with that also.
I'll see if I can find my GitHub credentials some time soon. I have them in a file somewhere. Been a while since I logged into GitHub.
-
Aug 14th, 2021, 01:28 AM
#267
Re: TwinBasic
Originally Posted by Niya
My apologies, I should have chosen my works more carefully. That is what I meant, the program crashes with an exception.
With regards to this issue. I was under the impression that this would qualified as syntax error and not a runtime error which I why I found that exception odd. If not using Set was a violation, I was expecting the compiler to prohibit compilation of the code.
This is good to hear.
I'll see if I can find my GitHub credentials some time soon. I have them in a file somewhere. Been a while since I logged into GitHub.
Ah OK, the runtime error is what is expected here; same as VB6. Without the 'Set', it gets default-member property-put semantics (through IDispatch with DISPID_VALUE). With IDispatch being late-bound, this is a runtime-error instead of a compile-error.
However, twinBASIC could be smarter than VB6 here, as it knows for sure that there's no default members defined on these internally defined classes, and so could throw a compile-error.
Last edited by WaynePhillipsEA; Aug 14th, 2021 at 02:49 AM.
-
Aug 14th, 2021, 02:16 AM
#268
Re: TwinBasic
v0.10.4333 just released. Handles-clause intellisense is now available, and the Debug object intellisense is also fixed.
-
Aug 14th, 2021, 02:47 AM
#269
Re: TwinBasic
Originally Posted by WaynePhillipsEA
Ah OK, the runtime error is what is expected here; same as VB6. Without the 'Set', the object on the RHS is probed at runtime for its default member through IDispatch (DISPID_VALUE), and then the result from that is passed on to the LHS object similarly using DISPID_VALUE, with property-put semantics. With IDispatch being late-bound, this is a runtime-error instead of a compile-error.
Wow, ok. I had no idea it worked like that. My knowledge of the internal workings of COM is no where near yours.
Originally Posted by WaynePhillipsEA
However, twinBASIC could be smarter than VB6 here, as it knows for sure that there's no default members defined on these internally defined classes, and so could throw a compile-error.
That would be a good idea. Errors like that don't exist in VB.Net or C# as far as I know. That's why it felt so weird to me. A general rule of thumb might be to consider any error that can be caught at compile time should be caught at compile time. This error qualifies but only for scenarios where the type being assigned is known.
Of course this is not what I'd consider a major pain. It would be acceptable if it stayed as it is provided we get a better description of why it crashed instead of just "unhandled error". The first time it happened to me, it took me quite a while to figure out that not using Set to assign objects to variables was the cause.
Originally Posted by WaynePhillipsEA
v0.10.4333 just released. Handles-clause intellisense is now available, and the Debug object intellisense is also fixed.
Just tried them. Works great so far!!
-
Aug 14th, 2021, 02:52 AM
#270
Re: TwinBasic
Originally Posted by Niya
It would be acceptable if it stayed as it is provided we get a better description of why it crashed
Absolutely. Most runtime errors come through as generic E_FAIL at the moment. There's an open issue for that (https://github.com/WaynePhillipsEA/twinbasic/issues/56), and we'll be tackling it very soon.
-
Aug 14th, 2021, 02:57 AM
#271
Re: TwinBasic
Originally Posted by WaynePhillipsEA
Ah nice.
One other thing on the intellisense, it doesn't work with RaiseEvent.
-
Aug 14th, 2021, 05:07 AM
#272
Re: TwinBasic
Originally Posted by WaynePhillipsEA
It would be great to see you over at GitHub, and it helps so others can keep track of issues too. That said, if you prefer to stay over here, I'm fine with that also.
There are some things that are making tB difficult and cumbersome to use, but should be easy to fix, thus worth the effort sooner.
Here is my feedback as a long time VB6/VB.NET user:
High
- Need Quick access to common menu items, in the same placement as VB6 and with the same naming convention. The learning curve is a bit of a nuisance, especially if what you're looking for doesn't exist yet. In fact any extra features that are not included in VB6 or laid out as VB6 should be hidden until chosen, or perhaps have 2 simple modes, ie classic mode/tB mode.
- Intellisense does not appear after typing the New keyword, ie Dim v As New {nothing appears here yet}.
- Intellisense does not initiate parameter/return types after typing spacebar (accepts only tab for some reason).
- Automatic Code formatting with options!!! There has never been an excuse for any IDE NOT formatting the code that is the format of the language itself. Code procedures should be displayed with a pretty arrangement after certain input events, ie Enter key, drag/drop, etc.
Moderate
- Make any new auto insertions optional (off by default). Muscle memory is hard and frankly annoying to change. The developer has to delete the extra inserted characters, or move the caret back because of an unexpected position. Getting used to this may not be possible since you have to switch back/forth to VB6 so often.
- Goto definition ?
- Jump to last postion?
- I'm Expecting the "Redo" shortcut accelerator to be Alt+Shift+Backspace, not Ctrl+Y
Low
- Object browser of some sort would be nice.
A smoother transition between VB6 and tB is needed for the user's experience. As mentioned, the developer will often have to switch back and forth between VB6 and tB. A good metaphoric example would be for users that switch between VB6 and VB.NET often. It takes a minute to jump back on the bicycle and remember the subtle differences that have a profound or opposite effect.
EDIT: update undo also has a bug, where it stops for no reason. Seems to be trying re-case or something?
Last edited by TTn; Aug 14th, 2021 at 05:32 AM.
-
Aug 14th, 2021, 06:55 AM
#273
Re: TwinBasic
Originally Posted by Niya
Ah nice.
One other thing on the intellisense, it doesn't work with RaiseEvent.
Fixed in v0.10.4359. (update will be live in about 5 minutes) Thanks!
-
Aug 14th, 2021, 06:56 AM
#274
Re: TwinBasic
Originally Posted by TTn
- I'm Expecting the "Redo" shortcut accelerator to be Alt+Shift+Backspace, not Ctrl+Y
@WaynePhillipsEA - I vote to keep Ctrl+Y if you decide to bind Alt+Shift+Backspace to Redo also. It has always driven me nuts that Ctrl+Y doesn't Redo in the VB6 IDE!
-
Aug 14th, 2021, 07:13 AM
#275
Re: TwinBasic
Thanks for your input @TTn.
> Quick access to common menu items
I hear you. Unfortunately VS Code doesn't offer full customization of menus (yet), so we can't copy the menu layout of VB6. At the moment, we've got the twinBASIC panel (with the build button etc), and so we probably need to make better use of that. In order to copy the layout VB6 more precisely, we'd have to fork VS Code, which is not impossible of course, but does have it's own concerns.
>Intellisense does not appear after typing the New keyword
Should already be fixed. This was a bug due to certain type libraries. Please let me know if you're version of tB is up-to-date and you're still experiencing this.
>Intellisense does not initiate parameter/return types after typing spacebar
This one is tricky. We can make the spacebar key do that, but it creates other problems. The issue comes from VS Code, where the intellisense dropdown list automatically pre-selects the top item, and so pressing space at that point then always changes the current entered text to the completion item text, even though you didn't manually select it. In VB6, it doesn't pre-select an item, so you don't have this problem. This one might be worth us creating an issue over on the VS Code repository to ask for an option to turn off the pre-selection of intellisense lists, and then we can more safely enable the traditional spacebar commit key.
> Automatic Code formatting with options
Planned.
> Make any new auto insertions optional (off by default)
Could you give me an example here, as we aren't doing much auto-insertion at the moment. Perhaps it was the automatic End-block statements you were referring to here? If so, we can add an option for that, sure.
> Goto definition
Already implemented. It's on the right-click context menu, or press F12.
> Jump to last postion
Not sure if VS Code offers that, but if not we could probably implement it.
> I'm Expecting the "Redo" shortcut accelerator to be Alt+Shift+Backspace, not Ctrl+Y
I'll look into that.
> Object browser of some sort would be nice
Planned.
> Update undo also has a bug, where it stops for no reason
Known issue. Sometimes 'Undo' fights with the tB prettifier. The prettifier currently wins.
Thanks!
-
Aug 14th, 2021, 09:26 AM
#276
Re: TwinBasic
Originally Posted by WaynePhillipsEA
> Quick access to common menu items
I hear you. Unfortunately VS Code doesn't offer full customization of menus (yet), so we can't copy the menu layout of VB6. At the moment, we've got the twinBASIC panel (with the build button etc), and so we probably need to make better use of that. In order to copy the layout VB6 more precisely, we'd have to fork VS Code, which is not impossible of course, but does have it's own concerns.
>Intellisense does not appear after typing the New keyword
Should already be fixed. This was a bug due to certain type libraries. Please let me know if you're version of tB is up-to-date and you're still experiencing this.
>Intellisense does not initiate parameter/return types after typing spacebar
This one is tricky. We can make the spacebar key do that, but it creates other problems. The issue comes from VS Code, where the intellisense dropdown list automatically pre-selects the top item, and so pressing space at that point then always changes the current entered text to the completion item text, even though you didn't manually select it. In VB6, it doesn't pre-select an item, so you don't have this problem. This one might be worth us creating an issue over on the VS Code repository to ask for an option to turn off the pre-selection of intellisense lists, and then we can more safely enable the traditional spacebar commit key.
> Automatic Code formatting with options
Planned.
> Make any new auto insertions optional (off by default)
Could you give me an example here, as we aren't doing much auto-insertion at the moment. Perhaps it was the automatic End-block statements you were referring to here? If so, we can add an option for that, sure.
> Goto definition
Already implemented. It's on the right-click context menu, or press F12.
> Jump to last postion
Not sure if VS Code offers that, but if not we could probably implement it.
> I'm Expecting the "Redo" shortcut accelerator to be Alt+Shift+Backspace, not Ctrl+Y
I'll look into that.
> Object browser of some sort would be nice
Planned.
> Update undo also has a bug, where it stops for no reason
Known issue. Sometimes 'Undo' fights with the tB prettifier. The prettifier currently wins.
- Ok, I understand that the menu layout may be hard, so expanding the tB panel makes sense.
- Yup, the New keyword is working here now.
- The spacebar issue is important because it hurts my wrist to extend out to tab key constantly, whereas both thumbs are planted at home on the spacebar, especially different keyboard layouts.
- Cool, manual code formatting is a subtle yet insidious distraction
- Type a function name, then type open parenthesis character or the open quotation character. There may be other examples but those kept slipping me up.
- Thanks for the tip on Goto definition, completely missed that.
- Jump back is nice but not needed right away.
- Redo is odd, because VB6 does accept Ctrl+Y, but it deletes lines of code. An accelerator is not listed on the menu item in the IDE. I expected to get Alt+Shift+Backspace, since VB.NET uses that alternative.
- Nice, object browsing!
- Prettify is difficult, but I'm sure you'll knock it out.
Last edited by TTn; Aug 14th, 2021 at 09:36 AM.
-
Aug 14th, 2021, 11:54 AM
#277
Re: TwinBasic
Originally Posted by jpbro
@WaynePhillipsEA - I vote to keep Ctrl+Y if you decide to bind Alt+Shift+Backspace to Redo also. It has always driven me nuts that Ctrl+Y doesn't Redo in the VB6 IDE!
I vote for Control+Y to do (keep doing) what it already does on VB6.
-
Aug 14th, 2021, 12:01 PM
#278
Re: TwinBasic
Originally Posted by Eduardo-
I vote for Control+Y to do (keep doing) what it already does on VB6.
I vote again for Ctrl+Y to do what almost every other Windows program does. We can vote more than once right? But seriously, I think it's easier to remap your brain once to a shortcut that works across all apps vs. having to remap it dynamically every time you task switch to another app.
Maybe customizable hotkey to action mapping (similar to what MZTools offers) is what's needed.
-
Aug 14th, 2021, 01:21 PM
#279
Addicted Member
Re: TwinBasic
Originally Posted by jpbro
I vote again for Ctrl+Y to do what almost every other Windows program does. We can vote more than once right? But seriously, I think it's easier to remap your brain once to a shortcut that works across all apps vs. having to remap it dynamically every time you task switch to another app.
Maybe customizable hotkey to action mapping (similar to what MZTools offers) is what's needed.
I never even knew about Ctrl+Y.
Comment and uncomment serves that purpose for me, I think
-
Aug 14th, 2021, 01:27 PM
#280
Re: TwinBasic
No voting required surely? These things should be sorted by configuration.
I mean we all use tools that are newer and do things the 'new' way but we old VB6ers are used to our old IDE, the way we have been using it for 20 years now. It is hard to unlearn. However, I'd be more than happy to use CTRL+R as a replacement for "find and replace" whereas old VB6 requires it to be CTRL+H. Give me the option to configure it exactly how I'd like and I am sure we will all be happy.
https://github.com/yereverluvinunclebert
Skillset: VMS,DOS,Windows Sysadmin from 1985, fault-tolerance, VaxCluster, Alpha,Sparc. DCL,QB,VBDOS- VB6,.NET, PHP,NODE.JS, Graphic Design, Project Manager, CMS, Quad Electronics. classic cars & m'bikes. Artist in water & oils. Historian.
By the power invested in me, all the threads I start are battle free zones - no arguing about the benefits of VB6 over .NET here please. Happiness must reign.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|