Open Source?? Edit

As a Visual Basic programmer for more than 15 years I am fairly certain that Microsoft never released their Visual Basic product as Open Source. I originally saw the reference to Virtual Basic on the main page and became curious. When I arrived and found reference to Microsoft Visual Basic I felt I had to ask for some verification that Visual Basic is Open Source since I have never found any evidence to support that and have been active in the VB community for many years. If you can steer me to a web page that offers VB Open Source I will gladly have a look. I think perhaps this reference is in the wrong category and should be moved to a more suitable category.

Where does it say VB is open source? Doomguy0505 06:14, 23 March 2007 (UTC)

Possibly you got this intention wrong, as the purpose of the classification "Open Source" in this context might be that VB script code published on this Wikia and scripted by the Wikia contributors can and will be classified as Open Source?
Just my 2c (€ cents) --IrasCignavojo 14:23, 10 April 2007 (UTC)

Guys, only one question: I see future in this wiki, but, speak all data relative to Microsoft's Visual Basic is only for Microsoft Users. I use Linux, and I use Gambas, and Gambas isn't mentioned in this wiki (even being the bigger Open Source Visual Basic desktop enviroment)... 90% of the Visual Basic data is fully compatible with Gambas, but what with uncompatible code? And VisualBasic.NET is another tale, they has changed part of the main code... Well, What do you expect, exactly, with this wiki? --DragonTrainer - Flamewars aquí, por favor. 15:26, 13 April 2007 (UTC)

Is there a link to this Gambas you speak of? --Doomguy0505 05:00, 21 April 2007 (UTC)

Here is Wikipedia info about Gambas: Gambas in Wikipedia and here is the main official site of Gambas: Official Gambas Site --DragonTrainer - Flamewars aquí, por favor. 22:41, 22 April 2007 (UTC)

Other "code repositories" often have a some small diagram showing which VB versions something is compatible with. Just use a template to simplify that. By the way, how open is this wiki to new stuff and such? Say I had a SHA-1 implementation, or a Tengwar Unicode-to-Dan-Smith-encoding converter? Also how does code contribution work here? Prefix all lines with a space and put it in a normal article, or upload file? Both? If so, is there an existing template to use? 11:23, 1 May 2007 (UTC)

You use the <pre> tag for code, and IMO, VB.NET is crap, the Script control doesn't work properly (or any COM components) --Doomguy0505 12:21, 1 May 2007 (UTC)
I'm not really into .NET myself. Still, it might be a nice courtesy to .NET folks to show if code is compatible or not. I've also added SHA-1.bas to Category:Code, assuming that's the appropriate location. Perhaps if this wiki gains some impetus I'll register and contribute some more; I'm also looking forward to the work of other contributors. 19:06, 5 May 2007 (UTC)

Since I have recently switched to Linux, I may be having a look into Gambas --Doomguy0505 10:40, 8 May 2007 (UTC)

Please inform us of your experience. Also please try to run VB using Wine - I'd be very interested in the results. If it mostly works, that's one less reason to stick with Windows. 15:28, 8 May 2007 (UTC)
I'll do it right now, not only for you; I'll do it for all interested people. Running Visual Basic under Ubuntu Linux. The test will not be complete today - Each day I'll making something.--DragonTrainer - Flamewars aquí, por favor. 13:06, 13 June 2007 (UTC)
Ah, thanks a lot! 14:05, 21 June 2007 (UTC)

What Visual Basic versions does this site covers? Edit

From the little that is here, it looks like most of the site supports Visual Basic 6.0. Do we want to have comparisons between all the different versions of visual basic or do we just want to support two or three versions? What versions are people interested in supporting? There is nothing on the site that talks about this. Personally I don't care what versions we support here, But I think we should at least cover versions 3, 6 and the latest .NET version. Dparvin 17:41, 15 June 2007 (UTC)

When I add code, it will have been tested using VB 4.0. Note that if you want to contribute a self-contained module of code, there's a template that makes it easy to track compatibility. Note however, that code written for VB classic will generally not be compatible with VB.NET, and vice versa, nor is it usually possible to do something about that. 15:41, 17 June 2007 (UTC)

Can someone add this category somewhere useful? Edit

Someone started Category:Questions, which is nice, but it's not linked anywhere, so few people find it. 05:16, 30 June 2007 (UTC)

Thanks, Doomguy0505! 03:43, 1 July 2007 (UTC)

Maximum number of files on project load Edit

Hi guys! In the documentation for Visual Basic 4.0 it says: "You can only open 384 files on project load." I thought that was a bit of strange limitation to put on a development tool, so I tested it by creating a project with 512 class modules. No problem, not even noticable delays. My best guess is that this is a typo and it originally read 16384 (= 2 ^ 14). Which raises another question... Why this number? Numbers like 2 ^ 15 - 1 or 2 ^ 16 - 1 could have been expected, but 2 ^ 14? And does this still apply in the 32-bit era? In other words, does this only apply to the 16-bit version, or to both the 16-bit and the 32-bit version? Anyone who has tried to do this with Visual Basic 4.0 or any other version and got strange results? 11:07, 24 August 2007 (UTC)

32-bit would probably be 1073741823, 2147483647 or 4294967295, not that you'd have enough memory to load it... --Doomguy0505 13:08, 18 October 2007 (UTC)

Scale method limits Edit

Hey guys, I've discovered something interesting about the Scale method. The difference between the maximum coordinate value and the minimum may not exceed 15000 times the number of pixels of the clientarea's width or height, sometimes plus one.

For example, a maximized window on a screen that's 1280 pixels wide

Scale (0, 0)-(19200000, 1)

still works, as do

Scale (0, 0)-(19200001, 1)
Scale (1, 0)-(19200002, 1)
Scale (0.5, 0)-(19200000.5, 1)


Scale (0, 0)-(19200002, 1)
Scale (0.5, 0)-(19200001.5, 1)

fail with error number 5 (Invalid procedure call).

This was on VB4. Do other VB versions have the same limit? Does anyone know of any technical reason underlying this issue? 16:29, 30 October 2007 (UTC)

Something weird happens when you return objects from methods with ParamArray'sEdit

First a bit of background to provide some context. When you return an object from a function or method, either through its return value or a ByRef argument, its reference count gets increased. When you throw an object reference away, its reference count gets decreased.

The semantics of calling a Visual Basic function, or function-like method are such that if you call them as a sub, or a sub-like method, the return value gets discarded. So you'd expect the following calls to always behave the same:

ReturnObject                      '(a)

Set Tmp = ReturnObject            '(b)
Set Tmp = Nothing

SomeObject.ReturnObject           '(c)

Set Tmp = SomeObject.ReturnObject '(d)
Set Tmp = Nothing

However, if you call a method which has a ParamArray, using syntax (d) will behave like expected, while syntax (c) forgets to decrease the reference count. It only happens when calling a method, not when calling a function in a standard module. It doesn't matter if the object is explicitly specified or not; With-blocks and local calls behave the same, which is to be expected. It only happens when the method has a ParamArray; Optional arguments, arrays, variants containing arrays, or a total absense of arguments are all okay as long as no ParamArray is present. It happens regardless of whether any arguments are actually specified on the call. It only happens with return values, not with ByRef arguments.

This happened to me on VB4; a minimal program displaying the problem:

Option Explicit

Sub Main()
Dim O As New Class1
End Sub
Option Explicit

Private Sub Class_Initialize()
Debug.Print "INIT"
End Sub

Private Sub Class_Terminate()
Debug.Print "TERM"
End Sub

Function ReturnObject(ParamArray Arguments()) As Class1
Set ReturnObject = New Class1
End Function

Note that Visual Basic keeps a list of all allocated objects that have not been destroyed yet. If your program stops, for whatever reason, all those objects are destroyed. (If the reason was that the "stop" button has been clicked, the Terminate event won't fire, even though the object does get destroyed.) This means that if you step through the example above, you will see TERM appear in the debug window eventually. If you wish, you can extend the program to demonstrate that the object indeed gets destroyed by Visual Basic's memory leak fixer and not the way it should be.

No clue what causes this. 18:06, 12 December 2007 (UTC)

Paintpicture annoyance Edit

I just discovered the hard way that Visual Basic's PaintPicture method calls StretchBlt instead of IPicture::Render. So much for clean object oriented design, code reuse and the principle that the picture probably knows better how to draw itself than you do. Thought I'd share. Anyway, considering the last few posts, perhaps we need a "Bugs and annoyances" page. 23:41, 18 February 2008 (UTC)

What would perhaps help this wiki to gain a bit more traction would be a way to release code under other licenses than the GFDL. Currently some of the code is licensed under a different license, but perhaps the GFDL applies to that code too? I don't know, but the GFDL doesn't offer the kind of protection that the GPL offers, so thinking it could apply might be holding people back. Perhaps there is a VB code repository that uses the GPL that we can link to? 19:16, 8 May 2008 (UTC)

Select Case crash :-) Edit

Paste this in a form:

Private Sub Form_Load()
Select Case Me
Case Form1
End Select
End Sub

Crash! 19:30, 21 March 2009 (UTC)

Visual Basic 4: Code LImits Edit

I was using the Select Case function within the Load procedure of my form in Microsoft Visual Basic 4 (Professional Edition, which cost $500+ when I bought it!), and I created a Case statement for each day of the year. In fact, I coded it so that for each Case, the Caption of 4 different labales would display specific information. When I ran the program, a pop-up error message said "Procedure too large." What I ended up having to do was create two user-defined sub-procedures that contained the Select Case code for the date instructions for four months of the year each, in addition to the code I had for the form's Load procedure.

I guess my concern is how can Microsoft, in the mid-1990s, create a $500 software program that actually limits how much code can be entered. I just assumed that when programming, there was endless lines of code that can be entered; the only problem might be how slow the program might run as a result.

Does anyone know what the exact limits are for text inside a procedure in Visual Basic 4? (i.e. no. of lines or no. of characters), and WHY would Microsoft do this in a Pro version? I mean, the whole Y2K problem was because older programming languages such as COBOL limited date info to 2 digits (the last 2 years etc.)...

Neil Dusseault

@I guess my concern: We already know that: because if your procedure is longer than a page or two you are almost certainly doing something horribly wrong. And by extension that if your solution just involves an artificail split, you're still doing it wrong. Yes, it's a limit, but it is a limit that doesn't matter, because if you hit it you already have worse problems.
@Does anyone: RTFM. And if you do that you'll also get a clue as to what causes this limit. 15:21, 8 June 2009 (UTC)

VB get bitmap from clipboard bug Edit

I just discovered that when VB tries to read an image from the clipboard, it doesn't take into account bitfields, resulting in a three pixel misalignment.

When VB reads an image from the clipboard in the DIB format, it obtains a pointer to the following data: header + bitfields + bits. When it then calls CreateDIBitmap, it supplies it with a pointer to this data, which is okay since it points to the header, but instead of also supplying it with a pointer to bits, it passes a pointer to bitfields. In other words, its offset calculation messes up because it calculates header + Len(header) instead of header + Len(header) + Len(bitfields).

I think think the only decent way to fix this would be to patch the runtime library in memory. Anyway, I thought you guys would find this interesting. 10:45, June 5, 2010 (UTC)