Yea I do that too. In addition, I also do it for cases where I know the return has a ridiculously long name like NetworkInformation. I'm also big on self documenting code so I tend to use ridiculously long names for my types too.
Printable View
Yea I do that too. In addition, I also do it for cases where I know the return has a ridiculously long name like NetworkInformation. I'm also big on self documenting code so I tend to use ridiculously long names for my types too.
So then the behavior of VB.NET is different? Const x = 100 in VB6 type inference rules would make that an Integer (VB6 Integer, 16bit signed). And you know what I meant by ambiguous, that it's not readily apparent and you have to dig into a complex rule set, *just like with VB6 Variant typing or consts*, which have resulted in untold hours running down hard to trace bugs, *because of the ambiguity*, and how unneccessarily easy it makes it for people, especially the beginners and people just trying to make quick tools for their actual work, BASIC is popular with.
Dear god, a prayer for any poor soul who has to maintain the code of their predecessor who thought "self documenting code" was a real thing.
Attachment 187436
It is a real thing. Here's some actual code from a small utility application used by a couple clients:-
There's no way I could read that code 15 years from now and not understand what it does and that's partly because I wasn't being stingy about naming things. I like nice long descriptive names.Code:Imports System.Globalization
Imports System.Windows.Markup
Public Class ItemDisplayLayoutsToBooleanConverter
Inherits MarkupExtension
Implements IValueConverter
Public Sub New()
End Sub
Public Sub New(ByVal curOption As ItemDisplayLayouts)
Me.CurrentOption = curOption
End Sub
Public Property CurrentOption As ItemDisplayLayouts
Public Function Convert(value As Object, targetType As Type, parameter As Object, culture As CultureInfo) As Object Implements IValueConverter.Convert
If TypeOf value Is ItemDisplayLayouts Then
Dim dataSourceValue As ItemDisplayLayouts = DirectCast(value, ItemDisplayLayouts)
If dataSourceValue = Me.CurrentOption Then
Return True
End If
End If
Return False
End Function
Public Function ConvertBack(value As Object, targetType As Type, parameter As Object, culture As CultureInfo) As Object Implements IValueConverter.ConvertBack
If TypeOf value Is Boolean Then
Dim b As Boolean = DirectCast(value, Boolean)
If b Then Return Me.CurrentOption
End If
Return Binding.DoNothing
End Function
Public Overrides Function ProvideValue(serviceProvider As IServiceProvider) As Object
Return Me
End Function
End Class
I think we view what's ambiguous in entirely different ways. As far as I'm concerned the rules in both VB6 and VB.Net are unambiguous. What I see as ambiguous is more like undefined behavior.
For example C/C++ is notorious for this. Reading outside the bounds of an array in C in undefined. It could crash your application, format your hard drive or do nothing at all. There is no defined behavior for this operation therefore it is ambiguous. A famous example would be the fast inverse square root function in the Quake source code. It's a C function that relies on a bunch of undefined behaviors. It worked at the time, but there is no telling how a modern C compiler would execute that code.
BASIC on the other hand was designed with very clearly defined behaviors. You read outside the bounds of an array in BASIC, it crashes with a specific error. There is no ambiguity there. When you do something like Dim x in VB6, the behavior is defined. In the absence of something like DefInt A-Z that would be a Variant. That is not ambiguous to me.
I think where we truly differ is that I believe the programmer should be held fully responsible for learning the language he is using, where as you seem to believe it is acceptable if he does not. Now don't me wrong. I don't know every single tiny thing about all the rules of VB.Net but when I make errors because I didn't understand a specific behavior, I blame myself, not Microsoft because chances are whatever I misused had clearly defined behavior that was documented.
:lol:
🤣
You seriously think clearly named variables are a substitute for documentation??
https://www.vbforums.com/images/ieimages/2023/04/18.png
https://www.vbforums.com/images/ieimages/2023/04/4.jpg
Obviously not but it helps.
I think that .NET is different in this regard, though I'm way too rusty with VB6 to be certain. Actually, it isn't .NET, either, it's VS. If you have Option Infer ON, then you can write something like this:
Dim X = 100
then hover over the X (assuming you can 'hover' over a single character), and you will see the type. No digging into rules is needed, as the IDE will tell you what type the variable will be.
Of course, if you wrote out the type, then in either language it is clear what the type will be, but if you aren't sure what the type will be, then you have to look it up, which you can do either online or by letting the IDE tell you. For example, if you have this:
Dim X = SomeFunctionWhoesReturnTypeYouDontKnow()
then hovering over the X will tell you what the type returned from the function is. Clearly, that has nothing to do with the language, just with the IDE, but it IS convenient.
Hi, dear Wayne
I'm a newbie to learn twinbasic this month. I tried to open my vb6 project directly in beta297, the import log and error report shows more than 1300 rows of errors(include a lot of repeat items). The main errors as followings,
1)in my main form
twinBASIC (IDE BETA 297) compilation error report:
{ERROR} ../Sources/Form/fMain.frm.twin [5,7]: Unexpected end of line
{ERROR} ../Sources/Form/fMain.frm.twin [6,5]: Syntax error. No handler for this symbol
2)In my main module
{ERROR} ../Sources/Module/mMain.bas [5,21]: Unrecognized datatype symbol 'fMain'
{ERROR} ../Sources/Module/mMain.bas [87,9]: Expression is neither used nor assigned
3)In my classes
{ERROR} ../Sources/Class/c2DChart.cls [1095,3]: Unrecognized member 'SetData' on type '_Clipboard' [non-extensible object]
{ERROR} ../Sources/Class/cMPFS_Function.cls [4143,40]: Invalid use of datatype hint
......
Maybe many errors are quite stupied,but so far I don't know what is a fast way to master the special grammar and bugfix skill about twinbasic, any documant or guide resources I can download from your site? Need your kind comment and suggestion. Thanks .
John
Clipboard.SetData (and GetData) aren't implemented yet; but I'd consider it a bug that it's giving an 'unrecognized member' error instead of an 'unimplemented' warning.
For the others, likely going to need more information about what's causing them... the more information you can provide the better the chances Wayne is able to address it quickly. The *best* way to report a bug is to recreate it in a minimal example; a new project with just enough code to reproduce the bug with as little extraneous code as possible. Of course sometimes that's not possible; next best would be to post the project or send it privately to Wayne. When that's not possible either, at least post the offending lines and any definitions (UDTs, APIs, etc) they rely on.
twinBASIC status update:
twinBASIC Update: April 23, 2023
Highlights include a status update from Wayne Phillips, extended discussion of twinBASIC on two web forums, and updates to fafalone's ucExplorer control.
https://nolongerset.com/twinbasic-update-april-23-2023/
TB import error is because the imported form name and the control name on the form cannot be in Chinese. If there is a Chinese Variables name, the import error will occur.
Hope to add support for more Unicode source codes and controlsIt would be better if all the controls could be set to be transparent, so that they could continue the background image of the previous layer.It can also be copied.
I hope to list this topic in the basic section. This is a commercial work, and a little advertising fee is allowed. Only for VB6, the life span is extended by 50 years.
I feel very sad that some other software like basic has been moved to other language forum categories. Basic is a very good language, and I hope more people can continue it.
VBForums>Other Languages>Other BASIC
I don't think he belongs to the basic language anymore. In fact, it is 100% compatible with VB6. He should put it in the real visual basic section, section, channel
Because put it in other columns, real Vb6 enthusiasts, it can be said that 99% of people can not see these messages, there are updates or such a good tool.
Unless a VB7 () visual basic 6 plus column is added and placed in the first section of the home page of the forum.
The tB native controls and source window all support Unicode.
Definitely need more developers from around the world to sort out bugs with the wonky VB6 Unicode implementation though. You might want to post a source file so Wayne can take a look at it; it's not necessarily easy to create examples with all the exact issues of VB6 without an actual Chinese installation/OS.
With control transparency, I think there's some limits in that for compatibility purposes, they have to be based on the same underlying Windows controls, so support for transparency is limited. The form itself can be transparent (including alpha blended with opacity from 0-100 setting), unlike VB6, at least.
Agreeing with xiaoyiao, the handling of transparency is essential to be rid of the old, non-layered, entirely separate, square-control MS paradigm. Once you've used a graphical framework that handles transparency naturally, ie. transparency is the delineation of the control's border - then you realise the power of what you can create graphically. Multi-layered, natural looking, graphical controls. It is a release.
New 'graphical' controls, with a property switch allowing click-through to underlying opaque controls. This is probably my one desire from TB over all others. You may not fully appreciate it but is a game changer for VB and would make TB a tool like no other. 64bit, graphical, transparency-handling with a compositing IDE with BASIC as its language. It would be a tool for everyone, from noobs/starters to professionals.
This is the approach MS took with WPF. All WPF controls are built from scratch with no foundation whatsoever on Windows controls so they have none of their limits. They can be subjected to all manner of graphical and geometric transformations to create just about any kind of UI you can imagine.
Yes, agreed and understood - and in that context, that is what I have really always wanted from VB6, with Olaf's work it is at least partly achievable. Hoping that TB will have that capability built-in and integrated via IDE and capability - at least some time in the near future. The benefits of a control without limits can only be appreciated once you have started building with them. Freedom and flexibility.
Olaf's widgets in RichClient are also based on Windows controls I believe as they have window handles. A new UI framework needs to be completely independent if you wish them to be free of the limits of Windows controls. WPF controls for example have no window handles and GDI cannot be used to render on their surfaces.
I think TwinBASIC users could look forward to such a framework because Wayne has made it clear that he intends to make TwinBASIC cross platform. One of the things it will need to achieve this is a platform independent UI framework.
That's not true - the RC5/6 Form+Widget-engine supports Alpha-Rendering fully at each nesting-level.
All you have to do, to adapt this engine to your specific needs,
is to add about 5 lines of self-written User-Code into the Widgets native HitTest-Event.
@Niya
The Widgets themselves work fully windowless (only TopLevel-Forms have a hWnd - no way around it on a Win-OS)-
the "siting-system" is based on normal COM-classes (normal COM-ABI with a VTable) -
and the only "other dependency" for it to work multi-platform, is the cairo-lib.
Olaf
It was true. I was stating it is at least partly achievable, implying specifically that some capability is definitely possible and potentially more. It might be a language thing that made you think I was implying otherwise.
No, it's still a wrong statement you made, since you claimed that certain "Alpha-capabilites are yet missing" in RC6 -
and that's just not true.
RC6 is smaller, faster and nevertheless has *much* more built-in functionality than the "old Yahoo-engine" you're comparing it to.
And of course it works a bit differently from that "very narrow, and specialized Yahoo-Widget-thingy" -
that's because it's a "general purpose framework" for a "general purpose, native compiling language".
Your own unwillingness to add some missing "out-of-the-box" feature with 5 extra-lines of VB-Code
(to ensure comparable behavior to the Yahoo-engine regarding "click-through-areas") is all what's holding you back.
Olaf
I never made that claim here on this thread, you are misquoting me. Probably looking for a battle. I'm not looking to be misquoted or have another argument with you Olaf, we know how easy those start. I know you love those battles and have history of them too - honestly, there is no point. I don't need to win a battle about RC5/6, not here, I'm not one of your detractors. This thread is about TwinBasic not RC/Cairo, it was just a mention and a positive one, which you misunderstood.
I am sure that is all true.Quote:
RC6 is smaller, faster and nevertheless has *much* more built-in functionality than the "old Yahoo-engine" you're comparing it to.
And of course it works a bit differently from that "very narrow, and specialized Yahoo-Widget-thingy" -
that's because it's a "general purpose framework" for a "general purpose, native compiling language".
I'm not - you made it repeatedly clear - (not only here, but also in other recent threads),
that "some things regarding Alpha-Handling are just not possible with RC6 as it currently is..."
(expressing your hope, that I add these allegedly missing "features" at a later time).
And that simply comes across "all wrong" ...
(because there's nothing I need to add to the Library, to make HitTesting work as you want it)
Instead it is up to you, who could add the following 5 lines into the W_HitTest-Event:
... to make an RC6-Widgets Click- and MouseHover-behavior comparable to the Yahoo-Widgets...Code:Private Sub W_HitTest(ByVal x As Single, ByVal y As Single, HitResultHit As Boolean)
Dim Srf As cCairoSurface, Pxl() As Long
Set Srf = Cairo.ImageList(W.ImageKey)
If Not Srf.BindToArrayLong(Pxl) Or W.Width = 0 Or W.Height = 0 Then Exit Sub
HitResultHit = Pxl(x * Srf.Width / W.Width, y * Srf.Height / W.Height)
Srf.ReleaseArrayLong Pxl
End Sub
It is also up to you, to ask for clarification (in case it is not immediately clear, what's happening in these 5 lines)...
That's what "normal people, interested in learning a so far unknown library" would do...
I'm only trying to clean-up your own misconceptions about RC6/Cairos Alpha-capabilities -
especially with regards to Widget-HitTesting (before others might "adopt them as truth").
And please stop, trying to paint me as a "raving lunatic" (constantly on the lookout for battle) -
... I'm trying to convey knowledge here - heck, even in my ".NET-fights with Niya" it was all about:
"how to do the same thing in as few lines of as possible in VB6"... stuff you could have learned from -
but instead your frustration "due to not understanding even half of it",
leads you to post "helpful, constant reminders" like the text in your signature...
It's not me, my friend - who's after you, believe me... (it's more like the opposite seems to be the case).
Olaf
Yes, let's say well you won that one then just to close it off. I'm not after you. I support your efforts. No-one said you were a lunatic, I just knew this was one going to go off the rails as always. Let's get back to TwinBasic.
PS. Just so you feel less of a target, I changed my signature.
Good that the situation was resolved. Now we can get back to TwinBasic.
Wait a sec....I swore I saw a post by fafalone last night right after uncle ber's post.
The mods apparently did not appreciate my wit :cool:
Just because there is a spark doesn't mean that you NEED to pour gasoline on it.
Well at least no one can accuse us of being boring :D
Niya, you have been demoted. You are no longer in my signature.
Aw shucks, now I can no longer impress the ladies :D
twinBASIC status update:
twinBASIC Update: DevCon 2023
Links and resources from Mike Wolfe's talk today at Access DevCon Vienna 2023, twinBASIC + Access: Future Plans.
https://nolongerset.com/devcon-2023-tb/
16 Best BASIC-like programming languages
https://www.slant.co/topics/9807/~ba...ming-languages
twinBASIC status update:
twinBASIC Update: April 30, 2023
Highlights include twinBASIC's annual DevCon Vienna appearance and fafalone's ucExplorer control running in 64-bit MS Access.
https://nolongerset.com/twinbasic-update-april-30-2023/
The discussion on the Return statement caught my eye. It occurs to me that all the problems surrounding it could be solved very easily......use a different name. Perhaps "Ret", like in assembly. All those problems go away just by using a different name for the statement.
twinBASIC status update:
twinBASIC Update: May 7, 2023
Highlights include a new Access library from Ben Clothier built with twinBASIC, a project status update from Wayne, and a couple of tB mentions in Reddit.
https://nolongerset.com/twinbasic-update-may-7-2023/
twinBASIC status update on YouTube
Learn about what the future of twinBASIC and Microsoft Access might look like from Mike Wolfe's Access DevCon Vienna 2023 presentation.
https://nolongerset.com/video-twinbasic-devcon-2023/
https://www.youtube.com/watch?v=Vq4ZFkeZyiA&t