Printable View
no, the idea is that C and VB have both the same operations, but they are called differently.Quote:
Originally Posted by PlausiblyDamp
so, a code:
>>=
Right shift assignment
so when in C-mode we have:
a >>= 2
when u switch to VB mode it will change to
a = RightShift(2)
or
RightShift a , 2
or
a RightShift 2
So changing the option would effectively rewrite the relevant parts of the code? Or would it store the code the same way under the hood and just display / translate in the editor based on your IDE choice? Rewriting sounds problematic if you are sharing your code via any source code control system as potentially a minor edit could cause a lot of changes to be saved, making it harder to track down what the actual change was when looking over the history.Quote:
Originally Posted by baka
the IDE need to parse anyway when u build/run/compile it.
and its not that u will keep changing modes.
people will have one or the other.
but, theres an option to "parse" the operations between C and VB.
the IDE itself can read both, meaning its possible to combine the 2 modes if one wants.
that means, when I run a project, and I notice, "he is using C mode", I can just click on the "VB-mode" and it will parse the entire project into VB-syntax.
if we are gonna use multiple syntaxes, it should be possible to have one or the other and there need to be a option in settings to be able to do that fast.
to do it manually takes too much time.
otherwise its a one-mans job, and it will be harder to share.
Quote:
Originally Posted by PlausiblyDamp
I know i'm contradicting myself (since i said i'm out of this discussion), but PD responded directly to my post, and i respect PD for his skills and opinion.
PD, everything true you said, but in case someone wrote his own "+="-operator, and he bugged it (e.g. his Return-Line reads "Return ALong - AStep" --> Note +/-),
well, his problem, not mine.
Because frankly: There wouldn't be a difference between his faulty operator or a faulty "classical" function
After following the discussion (not Fight! *g*) about this, I'm more on the ambivalent side now regarding this
(Since women are allowed to change their mind 20 times within 5 minutes, i think i, as a male, am allowed to change my mind once after some days, a fruitful discussion preceeding it):
We have it now as an intrinsic (as Wayne said: It's implemented). I don't have to use it (and i wouldn't since i grew up with "a = a + 1"), but noone should expect help from me asking why his "a += 1" is not working as expected.
EDIT: On a sidenote:
After my transition to FreePascal/Lazarus, i discovered in FPC/Laz that i can overload intrinsic operators.
In my case then it was the "+"-operator, which in FPC is used for addition as well as for String-concatenation.
I was asking on their forum, how i could "shorten" a
One answer was:Code:MyString:=SomeString+SomeInteger.ToString; //MyString:=SomeString+SomeInteger; produces an error since FreePascal is strictly typed, no implicit Type-Cast
Overload the "+"-operator, but beware: In this case if something doesn't work as expected, and you ask for help,
but you don't mention you've overloaded the operator,
then all gloves are off
I have a dislike of underscores leading or otherwise. It's not irrational, either. That underscore key is one of the most awkward you can type as a touch typist. Not a bit deal in C style languages, since they make so much use of symbols from the Shift+Number key area, but they aren't easy to type.Quote:
Originally Posted by jpbro
The double underscore was a way to indicate a certain type of function in something like MFC C++, if I remember right...but even if I DO remember right, I don't remember what the type of function was that used them. Something like "part of MFC, but not ANSI-Standard C++".
Why is FreePascal abbreviated to FPC? It seems like FP would make more sense. The C in there is just chosen as it starts a syllable, not a word. That's not done very often.
I actually use leading underscores in my VB.Net programs for class level variables. VB6 doesn't allow it so I use g_ prefix for class level variables in VB6.
FPC = Free Pascal CompilerQuote:
Originally Posted by Shaggy Hiker
Ah. That totally makes sense. Thanks for the clarification.Quote:
Originally Posted by Zvoni
twinBASIC status update:
https://nolongerset.com/twinbasic-up...ember-19-2021/
Highlights include support for importing VB6 project files (*.vbp), new MsgBox options, and a spirited discussion about what tB's design priorities should be.
twinBASIC now allowing import from VB6 projects (.vbp) is something many of us have been waiting for.
At the moment, only supported documents are imported (i.e. modules and classes, not forms). Once form import is supported, and VB6 forms are supported in the GUI (expected February) we should be able to convert existing VB6 apps to twinBASIC.
I tried to "import" a relatively small code with one subroutine, it is a tool to read an xlsx file and spit out a pdf output. After commenting out the codes for the form (disabling buttonts, etc.) it was able to spit out the pdf file just fine! My only concern is it was not able to compile the following code:
I am not sure if I need to reference something to make it work, and I don't even know how to make references in TB.Code:Screen.MousePointer = vbDefault
Quote:
Originally Posted by dee-u
You can report twinBASIC issues at https://github.com/WaynePhillipsEA/twinbasic/issues
I guess this may be dependent on the GUI Forms Editor being completed.
No, there is no reference that can help you with this because TB runtime (all the built-in objects like Screen, App, etc. in VBx) is not complete yet.Quote:
Originally Posted by dee-u
Your only option is to replace Screen.MousePointer object properties calls with Screen_MousePointer global properties (in a .bas file in *your* project) and provide empty stubs for these replacements (or reimplement them with API calls).
cheers,
</wqw>
so, I decided start using TwinBasic.
after installing it, I started coding for my next project.
the first thing is File-IO, so, CurDir, check if file exists and FileLen.
CurDir worked, returned a string,
after that I needed to get the length of a file, using FileLen, but I get an error. no matter if the file exists or not.
since I want to do everything using internal commands (not API as that could make a mess when cross-platform is here)
Im already stuck. after 1 minute of coding... will wait another year then...
@baka Not seeing any problem with FileLen here (tested with local files and network files), though bear in mind that the File-IO portion of twinBASIC has not long been completed.
Could you show me your code?
Attachment 183382
I figure it out.
the CurDir takes the Folder of VSCODE
FileLen(Sys.Root & "\data\initialize.txt")
I changed to
FileLen(Sys.Root & "\..\data\initialize.txt")
(I placed VSCODE in the folder where I will create the project so sys.root = CurDir would give me where VScode is)
here was the error I got when I tried the code:
so, its similar to VB6, I need to check if its in IDE or compiled.
but, how to know this? should I use:
CBool(App.LogMode = 0)
as I do in VB6? (but it gives me error in TwinBasic)
(I dont care for compatibility, I can use any new commands)
Just FYI, in the vast majority of cases, the tB runtime throws a generic E_FAIL error (&H80004005) for all types of failures, which is quite unhelpful... but this is an area we are currently working on, so this will improve greatly over the next few weeks. The github issue for tracking our progress on this is https://github.com/WaynePhillipsEA/twinbasic/issues/56Quote:
Originally Posted by baka
edit: did some research
thx.
so, its similar to VB6, I need to check if its in IDE or compiled.
this method is not working: CBool(App.LogMode = 0)
looking here: https://www.vbforums.com/showthread....ing-in-the-IDE
I found that this is working:
would be nice to have a "twinbasic" alternative, like IDEmode that returns True or FalseCode:Function RunningInVB() As Boolean
'Returns whether we are running in vb(true), or compiled (false)
Static counter As Variant
If IsEmpty(counter) Then
counter = 1
Debug.Assert RunningInVB() Or True
counter = counter - 1
ElseIf counter = 1 Then
counter = 0
End If
RunningInVB = counter
End Function
Yes, that's a good idea. I've just added App.IsInIDE boolean property in v0.13.53. The update should be available to you via the extensions bar on the left side of VS Code within about 10 minutes.Quote:
Originally Posted by baka
just tried it and it work well.
now I don't even need to place that property in a collection, I just call App.IsInIDE when needed. and because its boolean I simply
thx a lot! :)Code:If App.IsInIDE Then
now.. continuation of the project.
next will be a bit of file handling and all that.
will report when Im stuck again or theres a feature missing
(but this time after I do a bit more research)
Why wait one year? Report it and Wayne will most likely fix it within a week or so. Do realise that TwinBasic is heavily Alpha grade and that you should only be using it to test out how and why it fails.
If it does work then be happy otherwise think of a failure as being a valid test that proves a point, something yet to be implemented.
You wouldn't drive a car just 25% complete it its design phase... Where is that rear wheel?
Using App.IsInIDE has its downsides.
We need preprocessor conditional for RunningInIde i.e. instead of this
If App.IsInIde Then
<<lots of code here which is included in final executable>>End If
. . . something like this would be better
#If RunningInIde Then
<<lots of code here to be removed at compile-time>>#End If
. . . so that we don't bloat final executable with debugging code.
I already use this in VBx
Dim bInIde As Boolean
Debug.Assert SetTrue(bInIde)
If bInIde Then
<<code>End If
. . . and the C2 compiler is smart enough to prune <<code>> when the boolean variable is not set (always false) during native code compile.
We already have TWINBASIC const, might be good idea to add TWINBASIC_DEBUG or similar for while running under the debugger too.
cheers,
</wqw>
There are benefits to both ways... App.IsInIDE gives neater code than conditional compilation IMO. The optimizing compiler that is coming soon will also be able to prune the redundant code here... I'll make sure that it is treated as a simple inlined constant.
That said, a TWINBASIC_DEBUG compiler constant is also a good idea.
I see the use,
for me its usually just the CurDir and maybe some subclassing that I want to avoid during IDE.
so App.IsInIDE is good for my needs,
that doesn't mean another way should not be implemented
if I would know that I want "specific" stuff called in IDE, that would be nice.
Im thinking of usercontrols where I "simulate" something in IDE, that are not needed once compiled.
(I did have an idea in vb6, where in IDE you use pictureboxes to place pictures around, but compiled, the pictureboxes would be replaced by direct2d rendering, but I never started is, as I dont use usercontrol, it was just an idea that I wanted to do after my game project)
When I tried it the first time, I found a whole bunch of issues. Just report them and Wayne would fix them as soon as he could. This is one of the biggest areas where the community can actually contribute.Quote:
Originally Posted by baka
I've noted some heated discussion on this thread about syntax tuples, += etc and I'd like to make some observations
Lets take +=.
Lets take a step back to c (as this has been cited in arguments). Why did += exist?
Its likely that this was seen as a convenient way of incrementing a variable when iterating over an array. Think about that.
The answer to the question is not if a=a+1, a+=1 or Inc(a) should be used but that the language offers a way of iterating over an array, collection of objects without the need to manage an indexing variable
VBA solves this problem with the 'for each' construct.
There has also been discussion on tuples and functions as first class objects. VBA allows both, you just need a bit more boiler plate code to implement the functions. As for using tuples and simple little functions, this is fine if you are prototyping, i.e just doing a quick look see. If you are coding for real then both unnamed tuples and adhoc functions should be avoided like the plague. They have no place in a modern programming language. This is because unnamed tuples and ad hoc functions cannot be tested. You only want facilities in your programming language that allow your code to be fully tested before you put it into use.
So please, in your discussions, please try to take a much higher level perspective when considering what does and does not make a good update for twinBasic compared to vba.
For my two pennies worth, and to supplement the discussion of +=, I'd very much like to see the for each statement of twinbasic to be updated to allow multiple items
Code:for each myItem1, myItem2,myitem3 in myItems1, myitems2, myitems3
as this would remove the annoying requirement to have a indexing variable when iterating over one collection to operate on a matching collection.
But again this may not be high level enough, because it is relatively simple to emulate such a construct by writing zip and unzip functions (zip in the sense of a collection holding pairs from two or more arrays)
Something to mull over during the holiday period.
Cheers.
Thinking about it *very* highly unlikely iterating over an array has anything to do with += operatror.Quote:
Originally Posted by freeflow
IMO the shortcut exists because on *all* CPU architectures there are ADD and INC instructions and the original C was meant as a thin wrapper over ASM, a kind of portable ASM.
Using similar contrived logic I can surmise that back then in the '70 there were no real arrays and that's why C has pointers to deal with anything that looks like an array :-))
cheers,
</wqw>
That doesn't seem to be a reason why += exists, it seems like a reason why ++ exists, which it only does in C syntax. += is nothing more than a shorthand, whereas ++ is an increment operator.
I'd argue that arrays still don't exist, but it's pedantic.
x++ is INC reg while x+=5 is ADD reg, imm if we are going to make far fetched analogies.
What exactly is is x+=f(x)*g(y) we'll leave to the imagination of the readers.
cheers,
</wqw>
So I did actually propose this, way back in the day. To me, prefix vs postfix seems entirely logical. But I accept it may not be a natural fit for BASIC.Quote:
Originally Posted by wqweto
theres a reason why its called Basic
but, for me its ok to have += ++ -- == etc, as long theres alternatives,
we have:
Dim A&
Dim A as Long
its the same principle.
The reason for my observation is that in the C programming language ++ and += add/increment based on type of the target variable. Thus if myVar is an int of 4 then myVar+=1 increments myVar to 5, however, if myVar is a pointer then myVar+=1 adds to myVar the size of the type being pointed to such that myVar now points to the address of the next myVar type. You wouldn't do this if you were not effectively implementing a for each type mechanism.
The reason p++ increments by sizeof(referenced type) is because this is the only way pointer arithmetic makes sense i.e. *p is p[0] (first array item) and *(p+1) is p[1] (second array item) so it makes sense for p++ to point to second array item too (like p+1) so the address in p has to be incremented by sizeof(item type), not a single byte.Quote:
Originally Posted by freeflow
Pointer arithmetic is devised long before For Each or any collections/iterators (or any *objects* in first place) were a figment of imagination.
cheers,
</wqw>
We are not arguing about pointer arithmetic but about why += and ++ exist in the first place. Its about recognising patterns in code. 'For each' may not have been in the scope of the implementors of bcpl, b, c etc, but the pattern exists. Arrays/Matrices existed in maths long before programming came to be so its not surprising that the pattern of pointer arithmetic was recognised and Array syntaxes were introduced into programming languages as a useful notation. Recognising patterns and formalising them into a more concise syntax is how programming languages develop. The evolution of 'for each' is of course the map, filter and reduce methods, all of which depend on a pointer to a function, which of course evolved into syntax supporting anonymous functions.
That argument makes sense for ++, but not for +=. After all, += is just a shorthand for a = a + N. The long hand version works just the same as the shorthand version, regardless of what a is. That isn't the case for ++, exactly. For one thing, while you could write ++ as a = a + 1, that isn't necessarily the same thing, since the former is INC, while the latter is ADD.
It probably exists because someone thought it's more concise to do MyLongVar+=1 than MyLongVar=MyLongVar+1. I tend to agree. I don't use the latter at all if I don't have to.Quote:
Originally Posted by wqweto
twinBASIC status update:
twinBASIC update: December 26, 2021
Highlights include several improvements to the COM references list, a fix for the hidden dialog windows issue, and many discussions about possible tB features.
If you are working with pointer arithmetic then its more likely that += exists to be able to iterate the first dimension of a 2D array more easily e.g. if your linear allocation of memory represents data organised as an array(0 to 4,0 to 5) then arrayPtr+=5 will iterate 'rows' (the 0-4 dimension) of the 'Array'.
True, but so would arrayPtr = arrayPtr + 5.
I find it interesting that some people want to bite my head off when I suggested that including += was a good move because it was not "BASIC-like", yet some of those same people are fighting tooth and nail for having pointers in TwinBASIC. This is hilarious lol