Page 3 of 3 FirstFirst 123
Results 81 to 94 of 94

Thread: TwinBasic

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

    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
    38

    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,884

    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
    38

    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,884

    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,884

    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
    38

    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,884

    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
    38

    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,359

    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
    38

    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,041

    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
    38

    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,041

    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-; Today at 02:27 PM.

Page 3 of 3 FirstFirst 123

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