Page 3 of 5 FirstFirst 12345 LastLast
Results 81 to 120 of 192

Thread: TwinBasic

  1. #81
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Posts
    2,968

    Re: TwinBasic

    Quote Originally Posted by WaynePhillipsEA View Post
    Yes, this limitation is noted in the preview notes: https://www.twinbasic.com/preview.html

    You can add as many components as you like to the single source file though. Sorry about that.
    Hey, no problem, I'm sure this will eventually work. I'll be putting everything in *the* single source file for now.

    Btw, just read the list with limitations and couldn't find anything about multiple source files -- at least the bullet with this is not obvious to me.

    cheers,
    </wqw>

  2. #82
    Member
    Join Date
    Dec 2020
    Posts
    46

    Re: TwinBasic

    Quote Originally Posted by wqweto View Post
    Hey, no problem, I'm sure this will eventually work. I'll be putting everything in *the* single source file for now.

    Btw, just read the list with limitations and couldn't find anything about multiple source files -- at least the bullet with this is not obvious to me.

    cheers,
    </wqw>
    You're right, it should be in that list. It's currently further down in the 'Starting a new twinBASIC project' section. I'll get that sorted, thanks.

  3. #83
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Posts
    2,968

    Re: TwinBasic

    Are Consts at module level still disabled like in

    Code:
    Class cAsyncSocket
    
        Private Const MODULE_NAME As String = "cAsyncSocket"
    
    End Class
    This fails with "syntax error. no handler for this symbol" but

    Private MODULE_NAME As String = "cAsyncSocket"

    . . . works.

    Is this new syntax compiled to a member variable with an initializer?

    cheers,
    </wqw>

  4. #84
    Member
    Join Date
    Dec 2020
    Posts
    46

    Re: TwinBasic

    Quote Originally Posted by wqweto View Post
    Are Consts at module level still disabled
    Yes, this will be sorted this week.

    Quote Originally Posted by wqweto View Post
    Is this new syntax compiled to a member variable with an initializer?
    Yes, that's exactly correct. But... there's also a special symbol.... CurrentComponentName to help you out there

  5. #85
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Posts
    2,968

    Re: TwinBasic

    Quote Originally Posted by WaynePhillipsEA View Post
    Yes, this will be sorted this week.



    Yes, that's exactly correct. But... there's also a special symbol.... CurrentComponentName to help you out there
    Wow, now that's a mouthful! :-))

    Not sure if VB.Net has NameOf(MyClass), NameOf(MyMethod) and NameOf(MyParam) the way C# has but .Net languages are lacking compared to C/C++ as simple as __FILE__, __LINE__, __FUNCTION__

    cheers,
    </wqw>

  6. #86
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Posts
    2,968

    Re: TwinBasic

    This works in VB6/VBA

    Private Declare Function ArrPtr Lib "msvbvm60" Alias "VarPtr" (Ptr() As Any) As Long

    Public Sub Main()
    Dim arr() As Long
    Dim ptr As Long
    ptr = ArrPtr(arr)
    End Sub

    . . . but fails compiling with TB with "validation of call to 'ArrPtr' failed. argument for 'Ptr': cannot coerce type 'Long()' to [ByRef] 'Any()'"

    Changing API declare to Ptr() As Long fixes it but this would require separate API declare for each possible type for array's elements.

    This

    Class Test
    Public Sub Init()
    PassThis Me
    End Sub

    Public Sub PassThis(oRef As Test)

    End Sub
    End Class


    . . . fails with "unable to bind to reference; this is a read-only binder".

    Edit: Oh, it needs ByVal oRef As Test -- I get it :-))

    cheers,
    </wqw>

  7. #87
    Member
    Join Date
    Dec 2020
    Posts
    46

    Re: TwinBasic

    Quote Originally Posted by wqweto View Post
    This works in VB6/VBA

    Private Declare Function ArrPtr Lib "msvbvm60" Alias "VarPtr" (Ptr() As Any) As Long

    Public Sub Main()
    Dim arr() As Long
    Dim ptr As Long
    ptr = ArrPtr(arr)
    End Sub

    . . . but fails compiling with TB with "validation of call to 'ArrPtr' failed. argument for 'Ptr': cannot coerce type 'Long()' to [ByRef] 'Any()'"

    Changing API declare to Ptr() As Long fixes it but this would require separate API declare for each possible type for array's elements.

    This

    Class Test
    Public Sub Init()
    PassThis Me
    End Sub

    Public Sub PassThis(oRef As Test)

    End Sub
    End Class


    . . . fails with "unable to bind to reference; this is a read-only binder".

    Edit: Oh, it needs ByVal oRef As Test -- I get it :-))

    cheers,
    </wqw>
    Thanks @wqweto, these will be fixed in tomorrows release! Also, if I remember correctly, we made our version of VarPtr accept arrays natively.

  8. #88
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Posts
    2,968

    Re: TwinBasic

    This

    Class Test

    Private Property Get Data(ByVal First As Long, Optional ByVal Index As Long) As Long

    End Property

    Private Property Let Data(ByVal First As Long, Optional ByVal Index As Long, ByVal lValue As Long)

    End Property


    Public Sub Init()
    Data(3) = Data(4)
    End Sub

    End Class


    . . . fails with "too few arguments, expected at least 2 in call to 'Data'".

    Passing an explicit value for the optional Index parameter fixes it.

    Quote Originally Posted by WaynePhillipsEA View Post
    Thanks @wqweto, these will be fixed in tomorrows release! Also, if I remember correctly, we made our version of VarPtr accept arrays natively.
    Cool!

    Unfortunately my cAsyncSocket class is both using With MyUdt / End With in a few places *and* is raising events with RaiseEvent OnReceive (to be usefull for anything) so I'll have to wait a few more weeks to test porting my VNC server (headless and perfect match for TB testing).

    cheers,
    </wqw>

  9. #89
    Member
    Join Date
    Dec 2020
    Posts
    46

    Re: TwinBasic

    Quote Originally Posted by wqweto View Post
    This

    Class Test

    Private Property Get Data(ByVal First As Long, Optional ByVal Index As Long) As Long

    End Property

    Private Property Let Data(ByVal First As Long, Optional ByVal Index As Long, ByVal lValue As Long)

    End Property


    Public Sub Init()
    Data(3) = Data(4)
    End Sub

    End Class


    . . . fails with "too few arguments, expected at least 2 in call to 'Data'".

    Passing an explicit value for the optional Index parameter fixes it.



    Cool!

    Unfortunately my cAsyncSocket class is both using With MyUdt / End With in a few places *and* is raising events with RaiseEvent OnReceive (to be usefull for anything) so I'll have to wait a few more weeks to test porting my VNC server (headless and perfect match for TB testing).

    cheers,
    </wqw>
    I'll get that fixed as well -- thanks very much for looking at twinBASIC. I'll let you know once we've got those other two hurdles sorted as well. Thanks

  10. #90
    PowerPoster
    Join Date
    Jun 2013
    Posts
    5,419

    Re: TwinBasic

    Quote Originally Posted by WaynePhillipsEA View Post
    You can add as many components as you like to the single source file though.
    The "single file concept" can later be quite handy, when it comes to the "publishing" of small or midsized Demos...
    (only one file to upload to GitHub or Bitbucket, or to "drag into an Email").

    In that regard...
    Currently there are two files to "manage" a project:
    - ProjectName.code-workspace
    - ProjectName.twinproj

    The *.code-workspace (as a file-ending) is already associated with (VS)Code.exe (containing setting-defs in JSON-format).
    Whereas the *.twinproj is not associated with any executable currently...

    So, why not ship your VSCode-plugin-binaries with an additional little "TwinStarter.exe",
    which after installing the plugin is then already "registered" for the *.twinproj File-endings...

    The TwinStarter.exe will then get the chance, to "do a few things with the passed project-file" internally, as e.g.:
    - dynamically creating a *.code-workspace-file with the same ProjectName (in case there currently is none in the same folder)
    - for that, one could parse out a "leading JSON-header" (instead of the current "binary one")
    - and that header should be compatible with the JSON-format which is expected in a "normal *.code-workspace-file"
    - to be able to ensure the content of a potentially missing *.code-workspace-file,
    - which after that dynamic creation could then be used to start VSCode (indirectly) in turn ...
    - simply by calling ShellExecuteW with the *.code-workspace-filepath

    So, this new "JSON-header" (instead of the binary header+footer in *.twinproject files),
    basically contains the normal JSON-fields which are expected in a *.code-workspace-file,
    but also a few "additional JSON-nodes" (as e.g. references to additional "normal *.bas and *.cls files) -
    but of course also the informations which formerly sat in the binary header and footer of a *.twinproject.

    Ensuring "plain text" in files which contain code - also agrees better with later Repo-Uploads
    (to not confuse any "diff-processings" between file-versions).

    To conclude - I guess what I was trying to say is - please "empower" the *.twinproject files, making them more universal in:
    - not requiring a workspace-file (because the new TwinStarter.exe can ensure that dynamically)
    - only containing PlainText in the end (a leading JSON-header instead of the current binary ones)
    - codewise keeping their current ability to directly host module- and class-sections as a single-file code-container
    - whilst also offering the ability, to act more like a *.vbp (only containing relative references to *.bas and *.cls code-files)

    Olaf

  11. #91
    Member
    Join Date
    Dec 2020
    Posts
    46

    Re: TwinBasic

    Quote Originally Posted by Schmidt View Post
    The "single file concept" can later be quite handy, when it comes to the "publishing" of small or midsized Demos...
    (only one file to upload to GitHub or Bitbucket, or to "drag into an Email").

    In that regard...
    Currently there are two files to "manage" a project:
    - ProjectName.code-workspace
    - ProjectName.twinproj

    The *.code-workspace (as a file-ending) is already associated with (VS)Code.exe (containing setting-defs in JSON-format).
    Whereas the *.twinproj is not associated with any executable currently...

    So, why not ship your VSCode-plugin-binaries with an additional little "TwinStarter.exe",
    which after installing the plugin is then already "registered" for the *.twinproj File-endings...

    The TwinStarter.exe will then get the chance, to "do a few things with the passed project-file" internally, as e.g.:
    - dynamically creating a *.code-workspace-file with the same ProjectName (in case there currently is none in the same folder)
    - for that, one could parse out a "leading JSON-header" (instead of the current "binary one")
    - and that header should be compatible with the JSON-format which is expected in a "normal *.code-workspace-file"
    - to be able to ensure the content of a potentially missing *.code-workspace-file,
    - which after that dynamic creation could then be used to start VSCode (indirectly) in turn ...
    - simply by calling ShellExecuteW with the *.code-workspace-filepath

    So, this new "JSON-header" (instead of the binary header+footer in *.twinproject files),
    basically contains the normal JSON-fields which are expected in a *.code-workspace-file,
    but also a few "additional JSON-nodes" (as e.g. references to additional "normal *.bas and *.cls files) -
    but of course also the informations which formerly sat in the binary header and footer of a *.twinproject.

    Ensuring "plain text" in files which contain code - also agrees better with later Repo-Uploads
    (to not confuse any "diff-processings" between file-versions).

    To conclude - I guess what I was trying to say is - please "empower" the *.twinproject files, making them more universal in:
    - not requiring a workspace-file (because the new TwinStarter.exe can ensure that dynamically)
    - only containing PlainText in the end (a leading JSON-header instead of the current binary ones)
    - codewise keeping their current ability to directly host module- and class-sections as a single-file code-container
    - whilst also offering the ability, to act more like a *.vbp (only containing relative references to *.bas and *.cls code-files)

    Olaf
    Hey Olaf,

    Thanks for your thoughts. Ironically, in the early alpha builds we had a single file solution, which was a single code-workspace file that had the project file embedded into a configuration setting BLOB as base64 data (in the JSON file). It worked well for small project files, but it soon became apparent that the code-workspace file wasn't designed to handle large binary data, so we separated out the project file to improve the performance.

    I do like your idea, but the problem with using a temporary code-workspace file is that there is potentially no chance to save/propagate changes in the temporary code-workspace file back to the proposed dual-format file. To explain... When VS code informs extensions to cleanup and shutdown, the extensions have very tight restrictions on what they can do, and the time they get to do it in. During testing I noted VSCode extensions get roughly 1 second each to shutdown (sometimes less), and then... poof the extension process is destroyed abruptly -- if you try to save something at that point, you most certainly would end up causing corruption if there's even a small delay. Even executables that are started from the Node.js environment, such as the twinBASIC compiler get terminated abruptly alongside the extension host.

    Now it may be that we can come up with a reasonable solution to the above problem, but I'm not convinced it's possible to make it 100% reliable, and that concerns me.

    Ideally we'd provide the code-workspace file itself to VSCode via a virtual file system, so that we then get proper control of reading and writing the file. But unfortunately, I had already tried that method early on in development, and VSCode just didn't allow it.

    A solution might be to just make the code-workspace file optional, and have a default one created on-demand if you open the twinproj file in VSCode. That way, you can distribute just the twinproj file for simplicity.

    The file format for the twinproj file is binary because we allow binary files in the virtual file system, and formats like JSON are not great for binary data. The reason for allowing binary files is because you'll be able to put files (e.g. graphics) into the Resources folder soon, and they will be pushed directly into the built EXE/DLL resources at link time. For source control concerns, we will be offering git integration that works off the virtual file system in-memory, and so the actual binary file format that the project file is stored in won't matter.

  12. #92
    PowerPoster
    Join Date
    Feb 2017
    Posts
    3,149

    Re: TwinBasic

    Hello, congrats for your achievements!

    Since it is intended to have backward compatibility with VB6 I want to ask if there is any technical reason for not sticking to the original file format and system, I mean plain text for definitions and binary files for binary data.

    Text files:
    vbp
    bas
    frm
    cls
    ctl
    pag

    Binary files:
    frx
    ctx
    pgx
    res
    (better forget about vbw)

    You could add your own new keys and sections on the text files for the new properties and features, or even new text files if needed, and new binary files (and extensions) if needed for whatever new features not supported by the original format.

    The developers many times like to edit the files "by hand", but for being able to do that the files need to be easily readable and understable.

    That's my opinion (and wishes).

    I wish much success to you and also to Carles.

  13. #93
    Member
    Join Date
    Dec 2020
    Posts
    46

    Re: TwinBasic

    Quote Originally Posted by Eduardo- View Post
    Hello, congrats for your achievements!

    Since it is intended to have backward compatibility with VB6 I want to ask if there is any technical reason for not sticking to the original file format and system, I mean plain text for definitions and binary files for binary data.

    Text files:
    vbp
    bas
    frm
    cls
    ctl
    pag

    Binary files:
    frx
    ctx
    pgx
    res
    (better forget about vbw)

    You could add your own new keys and sections on the text files for the new properties and features, or even new text files if needed, and new binary files (and extensions) if needed for whatever new features not supported by the original format.

    The developers many times like to edit the files "by hand", but for being able to do that the files need to be easily readable and understable.

    That's my opinion (and wishes).

    I wish much success to you and also to Carles.
    Hi Eduardo,

    Thanks for your message. The plan is that all these formats will be supported, and natively.

    Think of the twinproj file like a ZIP container, but it will also allow links to external files. So you'll be able to open a VBP file in twinBASIC/VSCode, and that will get migrated to the twinproj format, with links to the individual files (.bas, .cls, etc). The VBP file will be kept in-sync with the new twinproj format, and this will be effectively invisible to the developer.

    The .twin file format is naturally different, because there is no way we can represent that in the old VB6 file formats at all, since you can't have multiple components per file, but all the original VB6 file formats will be supported via file links. Just not for this preview

  14. #94
    PowerPoster
    Join Date
    Feb 2017
    Posts
    3,149

    Re: TwinBasic

    Quote Originally Posted by WaynePhillipsEA View Post
    there is no way we can represent that in the old VB6 file formats at all, since you can't have multiple components per file
    Thanks for responding Wayne,

    I don't know why you need multiple components per file, what are these components and why they cannot be written all together, the text part into a text file and if they have a binary part into a companion file (as VB6 does).

    But I don't know what you are doing. I just have some insights into your project but I still didn't test anything (I've been currently busy with other things, but I'm very interested of course).
    Aside from that, in my case the last 10 times that I said something was impossible 9 I was wrong.
    But if you say so, it must be.

    Regards.

    Edit: I mean text files UTF-8 encoded, with some keys Base-64 encoded if necessary.
    Last edited by Eduardo-; Apr 11th, 2021 at 02:27 PM.

  15. #95
    Addicted Member
    Join Date
    Feb 2015
    Posts
    248

    Re: TwinBasic

    An article about additional features in the VB6 compatible twinBASIC...

    New Syntax in twinBASIC: Part 1

  16. #96
    Member
    Join Date
    Dec 2017
    Posts
    32

    Re: TwinBasic

    May I make a little suggestion? A compiler option to enforce assignment and equality/inequality (= and ==/!=) syntax, as in C and other languages. I guess it only makes sense by producing an appropriate warning if a "=" is used in a comparison.

  17. #97
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Posts
    2,968

    Re: TwinBasic

    Quote Originally Posted by immortalx View Post
    May I make a little suggestion? A compiler option to enforce assignment and equality/inequality (= and ==/!=) syntax, as in C and other languages. I guess it only makes sense by producing an appropriate warning if a "=" is used in a comparison.
    Why? Assignment is never an expression i.e. something like IIf(Total = 0, 0, 42) will never assign 0 to Total and Count = Total = 42 will never assign 42 to Count (nor Total) so BASIC is safe regarding this C-world idiosyncrasy.

    cheers,
    </wqw>

  18. #98
    Member
    Join Date
    Dec 2017
    Posts
    32

    Re: TwinBasic

    No reason other than habit, readability and being able to more easily port C stuff.

  19. #99
    PowerPoster
    Join Date
    Jun 2013
    Posts
    5,419

    Re: TwinBasic

    Quote Originally Posted by WaynePhillipsEA View Post
    A solution might be to just make the code-workspace file optional, and have a default one created on-demand if you open the twinproj file in VSCode. That way, you can distribute just the twinproj file for simplicity.
    I'd appreciate, when at least that will work in the future.
    And as for "back-syncing" into the twinbasic-projectfile... (from the dynamically created workspace-file).

    If it succeeds, all is well - and the "TwinStarter.exe" could override the "last temporary workspace-file" with it.
    If it does not succeed (or was left out) - then "TwinStarter.exe" could use:
    - either the last temporary workspace-file
    - or if there isn't one yet for the project-file, then dynamically create one with the default-settings

    Quote Originally Posted by WaynePhillipsEA View Post
    The file format for the twinproj file is binary because we allow binary files in the virtual file system...
    The only binary files which come to my mind, are image-files (or perhaps Font-Files)...
    And *especially* these should go into a different, isolated location in the filesystem.

    You might want to take a look, how "all kind of resources" *could* be handled
    (conveniently, behind a \Res\ SubFolder below the Poject-Path, where you can place anything):
    https://www.vbforums.com/showthread....ontainer-Files

    According to the above example - what you will end up with - is a single Res.zip file -
    which in turn could be "hung in" into the final binary as a "single ByteArray-resource" in a post-compile-step automatically.

    I also don't see the "big advantage" of dealing with the "virtual file-structure" you currently have.
    ...IMO, the Node.js fs-module is capable enough to deal with "normal Files" in a performant manner
    (with free choice, to do certain methodcalls synch-, or asynchronously).

    And if I read the VSCode-docu correctly - its "workspace" should be able to provide you with
    proper "filechange"-events also for normal files.

    JFYI - the main-VB6 project at the place where I work, has literally "hundreds" of modules and classes
    (when combined in certain Debug-Groups)... meaning "Megabytes of Code" to compile for a debug-run.
    I cannot imagine that VSCode will not choke, when such an amount of modules shall be handled in "virtual mode".

    And as for the "binary-format" (binary-blocks) on your project-file ...
    I'm quite sure I'm not the only one here, who would (quite strongly) prefer "plain-text" for that important "entry-point-into-a-given-project".

    Cannot count the times and occasions, where I've written (or used) tools,
    which performed different operations on all kind of VB-sourcefiles (without involving the VB6-Executable at all).

    Olaf

  20. #100
    Member
    Join Date
    Dec 2020
    Posts
    46

    Re: TwinBasic

    Quote Originally Posted by Schmidt View Post
    You might want to take a look, how "all kind of resources" *could* be handled
    (conveniently, behind a \Res\ SubFolder below the Poject-Path, where you can place anything):
    Yes, that is pretty much what we have planned. We already have the Resources folder in the project virtual file system ready for this. Files in there will be embedded at build time automatically into the PE file resources section, and they will be exposed conveniently through the object model at runtime.

    Quote Originally Posted by Schmidt View Post
    I also don't see the "big advantage" of dealing with the "virtual file-structure" you currently have.
    ...IMO, the Node.js fs-module is capable enough to deal with "normal Files" in a performant manner
    (with free choice, to do certain methodcalls synch-, or asynchronously).
    Absolutely, I agree. That wasn't a factor in the decision.

    The main reason for the current design is so that we can, in future, support in-memory VBA streams (which are IStorage based). This design is extremely flexible, in allowing for both in-memory streams as well as on-disk files. The further benefit of being able to distribute a simple one-file project solution is also particularly useful.

    Quote Originally Posted by Schmidt View Post
    JFYI - the main-VB6 project at the place where I work, has literally "hundreds" of modules and classes
    (when combined in certain Debug-Groups)... meaning "Megabytes of Code" to compile for a debug-run.
    I cannot imagine that VSCode will not choke, when such an amount of modules shall be handled in "virtual mode".
    Oh believe me, VS Code will handle this just fine. The virtual file system is actually implemented within the twinBASIC compiler (written in C++), with VS Code connecting to it via raw socket requests. Believe me, we have extensively tested it, and there is absolutely no performance concern with the scenario you describe.
    Last edited by WaynePhillipsEA; Apr 12th, 2021 at 02:10 PM.

  21. #101
    Addicted Member
    Join Date
    Feb 2015
    Posts
    248

    Re: TwinBasic

    I have to say how impressed I have been with twinBASIC so far. Good work, Wayne.

    Are you planning to publish a roadmap for twinBASIC - when can we expect Forms/GUI support?

  22. #102
    Fanatic Member TTn's Avatar
    Join Date
    Jul 2004
    Posts
    605

    Re: TwinBasic

    Quote Originally Posted by WaynePhillipsEA View Post
    No, not in preview 1. They will be supported in due course though, so watch this space.
    Also on my wish list is having compile switches similar to VB. Compile switches from Advanced Microsoft Visual Basics (second edition)

    The output of c2 hooked in a default project is:
    Code:
    C3 -il "C:\Users\user\AppData\Local\Temp\VB430308" -f "Form1" -W 3 -Gy -G5 -Gs4096 -dos -Zl -Fo"C:\Users\user\Desktop\Form1.OBJ" -QIfdiv -ML -basic
    The output of link is:
    Code:
    L1NK "C:\Users\user\Desktop\Form1.OBJ" "C:\Users\user\Desktop\Project1.OBJ" "C:\Program Files (x86)\Microsoft Visual Studio\VB98\VBAEXE6.LIB" /ENTRY:__vbaS /OUT:"C:\Users\user\Desktop\Project1.exe" /BASE:0x400000 /SUBSYSTEM:WINDOWS,4.0 /VERSION:1.0   /INCREMENTAL:NO /OPT:REF /MERGE:.rdata=.text /IGNORE:4078
    Is it possible to keep that string format compatible?
    Last edited by TTn; Apr 12th, 2021 at 07:18 PM.

  23. #103
    Member
    Join Date
    Dec 2020
    Posts
    46

    Re: TwinBasic

    Quote Originally Posted by TTn View Post
    Also on my wish list is having compile switches similar to VB. Compile switches from Advanced Microsoft Visual Basics (second edition)

    The output of c2 hooked in a default project is:
    Code:
    C3 -il "C:\Users\user\AppData\Local\Temp\VB430308" -f "Form1" -W 3 -Gy -G5 -Gs4096 -dos -Zl -Fo"C:\Users\user\Desktop\Form1.OBJ" -QIfdiv -ML -basic
    The output of link is:
    Code:
    L1NK "C:\Users\user\Desktop\Form1.OBJ" "C:\Users\user\Desktop\Project1.OBJ" "C:\Program Files (x86)\Microsoft Visual Studio\VB98\VBAEXE6.LIB" /ENTRY:__vbaS /OUT:"C:\Users\user\Desktop\Project1.exe" /BASE:0x400000 /SUBSYSTEM:WINDOWS,4.0 /VERSION:1.0   /INCREMENTAL:NO /OPT:REF /MERGE:.rdata=.text /IGNORE:4078
    Is it possible to keep that string format compatible?
    Thanks for the request. Sure, once we add command-line compilation support, we'll certainly make sure the switches match as much as possible.

  24. #104
    Member
    Join Date
    Dec 2020
    Posts
    46

    Re: TwinBasic

    Quote Originally Posted by VB6 Programming View Post
    I have to say how impressed I have been with twinBASIC so far. Good work, Wayne.

    Are you planning to publish a roadmap for twinBASIC - when can we expect Forms/GUI support?
    Thank you very much! Indeed, a detailed roadmap will be published in the coming weeks.

  25. #105
    Addicted Member
    Join Date
    Feb 2015
    Posts
    248

    Re: TwinBasic

    Articles about additional features in the VB6 compatible twinBASIC,
    including AndAlso, OrElse, Continue For and Return.
    These are additions to the VB6-compatible language and may be familiar to VB.Net users.

    New syntax in twinBASIC part 1

    New syntax in twinBASIC part 2

    New syntax in twinBASIC part 3
    Last edited by VB6 Programming; Apr 15th, 2021 at 04:08 AM. Reason: Part 3 added

  26. #106
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Posts
    2,968

    Re: TwinBasic

    The new ternary If operator is a missed opportunity for this to compile in TB

    Dim a As Variant, b As Variant

    If(True, a, b) = 10


    The point is that in C/C++ the ternary operator preserves value category (here being l-value) so that the analogous snippet works just ok.

    In C/C++ this (expr ? a : b) is replaced by something like *(expr ? &a : &b) so that ternary operator works even with struct member access like this snippet

    MyStruct a, b;

    (true ? a : b).MyField = 5;


    cheers,
    </wqw>

  27. #107
    PowerPoster
    Join Date
    Feb 2017
    Posts
    3,149

    Re: TwinBasic

    Quote Originally Posted by wqweto View Post
    If(True, a, b) = 10
    I don't see how that could be of much use.

    But instead:

    Code:
    x = If(condition, a, b)
    similar to current IIF, but where the False part is not evaluated beforehand.

  28. #108
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Posts
    2,968

    Re: TwinBasic

    The sample is contrived but it's used in C/C++ so it must be of some use to somebody. (To me for instance.)

    The False part is not evaluated in C/C++ as well and there are no non-short-circuit logical operators in C/C++ like the And/Or debacle in VB6. Not sure there is any other language lacking short-circuit operators like VB6 to be honest. Probably only VB5. . .

    cheers,
    </wqw>

  29. #109
    PowerPoster
    Join Date
    Feb 2017
    Posts
    3,149

    Re: TwinBasic

    About the ternary that you propose, I can't think where I would need that.

    Also, in VB6 it can be done like this:

    Code:
    If condition Then a = 10 Else b = 10
    But the other one, could have some uses IMO:

    Code:
    FontName = If(nFont is Nothing, "Arial", nFont.Name)
    Last edited by Eduardo-; Apr 14th, 2021 at 10:03 AM.

  30. #110
    Fanatic Member TTn's Avatar
    Join Date
    Jul 2004
    Posts
    605

    Re: TwinBasic

    Quote Originally Posted by Eduardo- View Post
    About the ternary that you propose, I can't think where I would need that.

    Also, in VB6 it can be done like this:

    Code:
    If condition Then a = 10 Else b = 10
    But the other one, could have some uses IMO:

    Code:
    FontName = If(nFont is Nothing, "Arial", nFont.Name)
    If the condition is a slow synchronous function return, then it does makes sense. In vb6, If/Else is not two conditions though?

  31. #111
    PowerPoster
    Join Date
    Feb 2017
    Posts
    3,149

    Re: TwinBasic

    Quote Originally Posted by TTn View Post
    If the condition is a slow synchronous function return, then it does makes sense. In vb6, If/Else is not two conditions though?
    Sorry, but about which one are you talking about?
    The one I proposed is like IIF but short-circuited (does not evaluate both as IIF does).

    The one that wqweto proposed is to assign a value to different variables (to one or the other) based on certain condition.

  32. #112
    Hyperactive Member
    Join Date
    Aug 2020
    Posts
    267

    Re: TwinBasic

    I tested twinBasic and it is really exciting.

    It's of course a good thing to see that twinBasic has added some new language features. But I'm thinking about a question:
    twinBasic has its own Basic language features (mainly similar to VB.NET), then Olaf's VB.Next will also have its own Basic language features, and RadBasic will also have its own Basic language features.

    If this is the case, then the Basic code accepted by these three compilers cannot be unified. Maybe we should have a Basic standardization organization like ECMAScript.

  33. #113
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Posts
    2,968

    Re: TwinBasic

    Quote Originally Posted by Eduardo- View Post
    The one that wqweto proposed is to assign a value to different variables (to one or the other) based on certain condition.
    This is not new to VB6 language as an l-value "feature" -- consider Mid function vs Mid statement:

    chunk = Mid$(s, 5, 10)

    Mid$(s, 5, 10) = "abcdef"


    Yes, Mid statement is unique but then new If ternary operator can follow.

    cheers,
    </wqw>

  34. #114
    PowerPoster
    Join Date
    Feb 2017
    Posts
    3,149

    Re: TwinBasic

    Quote Originally Posted by wqweto View Post
    This is not new to VB6 language as an l-value "feature" -- consider Mid function vs Mid statement:

    chunk = Mid$(s, 5, 10)

    Mid$(s, 5, 10) = "abcdef"


    Yes, Mid statement is unique but then new If ternary operator can follow.

    cheers,
    </wqw>
    Yes, I know.
    I don't want to argue, just wonder for a real case use.

  35. #115
    Member
    Join Date
    Dec 2020
    Posts
    46

    Re: TwinBasic

    Quote Originally Posted by Eduardo- View Post
    Yes, I know.
    I don't want to argue, just wonder for a real case use.
    I'll be happy to consider the syntax suggested by @wqweto, though I do wonder how many developers would actually use that form. I'll be creating a github repo just for issue tracking and feature requests in the next day or so. Once we've got that set up, I would ask that you post your suggestion over there, and then others can comment on it before we make a decision.

    BTW, twinBASIC already supports the ternary short-circuiting If() operator function in expressions.

    Thanks for all the support / suggestions / bug reports so far! Much appreciated.

  36. #116
    Member
    Join Date
    Dec 2020
    Posts
    46

    Re: TwinBasic

    twinBASIC issue tracking is now live at github. We've been inundated with bug reports and feature requests from many different sources. Going forward, it would help immensely if you could report bugs and post feature requests over at the repository which will help us better keep track and manage requests.

    https://github.com/WaynePhillipsEA/twinbasic
    https://github.com/WaynePhillipsEA/twinbasic/issues

    Tomorrow we'll put up all the existing known issues as currently listed on the main website. Thanks!

  37. #117
    PowerPoster
    Join Date
    Jun 2013
    Posts
    5,419

    Re: TwinBasic

    Quote Originally Posted by WaynePhillipsEA View Post
    I'll be happy to consider the syntax suggested by @wqweto, though I do wonder how many developers would actually use that form.
    I actually use even VBs current IIF() kinda like that with objects
    (often when filtering into "two different baskets" like the code below shows):

    Code:
    Private Sub Form_Load()
      Dim Num, Evn As New Collection, Odd As New Collection
      
      For Num = 0 To 9
          IIf(Num Mod 2, Odd, Evn).Add Num
      Next
      
      Debug.Print vbLf; "Even Numbers: ";
      For Each Num In Evn: Debug.Print Num;: Next
      
      Debug.Print vbLf; "Odd  Numbers: ";
      For Each Num In Odd: Debug.Print Num;: Next
    End Sub
    Prints out:
    Code:
    Even Numbers:  0  2  4  6  8 
    Odd  Numbers:  1  3  5  7  9
    If there's more than two different "target-objects" to decide between... the Choose()-function can be used in a quite similar manner.

    Olaf

  38. #118
    Member IndicSoftware's Avatar
    Join Date
    Aug 2017
    Location
    India
    Posts
    56

    Re: TwinBasic

    Quote Originally Posted by SearchingDataOnly View Post
    I tested twinBasic and it is really exciting.

    It's of course a good thing to see that twinBasic has added some new language features. But I'm thinking about a question:
    twinBasic has its own Basic language features (mainly similar to VB.NET), then Olaf's VB.Next will also have its own Basic language features, and RadBasic will also have its own Basic language features.

    If this is the case, then the Basic code accepted by these three compilers cannot be unified. Maybe we should have a Basic standardization organization like ECMAScript.
    A good idea but actually it is not practical as there are a huge number of Basic variants in the market.
    --
    For,
    Indic Software

    Murphy's law: Logic is a way of coming to the wrong conclusion with confidence !!!

  39. #119
    Fanatic Member
    Join Date
    Feb 2014
    Location
    Norfolk UK (inbred)
    Posts
    846

    Re: TwinBasic

    Quote Originally Posted by IndicSoftware View Post
    A good idea but actually it is not practical as there are a huge number of Basic variants in the market.
    But surely that would help standardise and potentially reduce the number of those variants? It also makes it much easier for any developer as you can re-use the documentation and testing methodology for any version of basic following the standard. No need to rewrite the book.

    A developer I know wasted huge amounts of time developing an IDE, a forms developer, a whole development environment only to fall at the last fence because he failed to understand the advantages of maintaining compatibility with the product that came before. Developers are generally bad at documentation. He did not realise that if he stood on the shoulders of giants he was much more likely to succeed. As it was, he went on a slightly different technical route which could not take advantage of all that had been achieved thus far in the past 5 years. His product was 90% complete, in parts it was very good - it failed despite that as it had no documentation, was incompatible, migration was difficult due to the technical differences and due to the massive workload he had taken on (due to the technical differences) he was unable to produce a bug free and usable product.

    A BASIC standard along the ECMA methodology would be a very desirable thing to have and simply following VB6 in all its peculiarities would mean one step toward that - no one would need to be retrained and all existing documentation and sample code/bug fixing would apply. Yet-Another-BASIC-Variant is not what we need and I applaud RADBasic in that developer's efforts to attain this or at least have it as his goal.

    This was the IDE that failed. You click on the program running on your desktop, click EDIT. Full transparency of all objects, use of VBscript or .js as you desired.



    It was good, at least this bit was. Closed source, dead and gone forever, no more development because he forgot what benefits standardisation brings and how compatibility is vital.
    Last edited by yereverluvinuncleber; Apr 15th, 2021 at 04:04 AM.

  40. #120
    Frenzied Member
    Join Date
    Jun 2012
    Posts
    1,775

    Re: TwinBasic

    If TwinBasic claims to be VBA/VB6 compatible at the end than this is "enough standards" and all pluses what come on top does not need to be synced with other basic variants. IMO

Page 3 of 5 FirstFirst 12345 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width