In vb6 there were control arrays with Index.
The index was useful: It could be used to handle a parallel set of control. In My example, there is a row of buttons, and a row of images, each button affects each image, respectively.
but(1) but(2) but(3)
img(1) img(2) img(3)
thus i could do something like...
but_click(index)
img(index).do_something()
Is there another way in VB.NET to do that, besides creating 2 arrays in design time and writing code to manage these arrays?
Is there another way in VB.NET to do that, besides creating 2 arrays in design time and writing code to manage these arrays?
No, and there shouldn’t be. This is a good thing. Many people, when coming from VB6 to VB.NET, miss control arrays. But in reality it’s the other way round: VB.NET doesn’t have control arrays because it doesn’t need them any more, controls can be put into normal arrays and collections (in VB6, control arrays were a hack to work around the fact that you couldn’t create normal arrays of controls).
The only difference is that the forms designer doesn’t support this. Which is also nor surprising if you think about it: control arrays are intrinsically dynamic, it makes no sense to create them statically at design time, you have to manage them in code.
Related
For integer keys the speed of indexing is O(N), so it looks like it is a list. But apparently (wqw's comment in Unable to properly loop through keys AND values in a VB6 For Each loop) access time for string keys is O(log(N))... Maybe it is a tree built on top of single-linked list (indexing the list elements)?
I tried hard to get the documentation about this, but all I can find is how to use the Collection, never what is its data model.
I doubt you'll find much of anything regarding the implementation details of VBA.Collection. (Official usage reference at https://learn.microsoft.com/en-us/office/vba/language/reference/user-interface-help/collection-object)
The general advice is to consider using the VBScript Dictionary object instead; certainly use that instead if you need access to the keys. According to this, Dictionary is also faster up to a point: https://fastexcel.wordpress.com/2012/07/10/comparing-two-lists-vba-udf-shootout-between-linear-search-binary-search-collection-and-dictionary/
Another alternative I've done myself was to make use of the .NET Hashtable (making reference to mscorlib.dll). I've not done any performance tests of that versus VBScript Dictionary, so I don't if it's worth the effort (but it was fun to implement). An example is at Cannot iterate Hashtable in VBA (Excel).
This is not a subjective question; I am mainly asking to see if structures are now deprecated or something in VB.NET.
It is also not generally a duplicate of a question asking when to use a structure or a class, as this is largely checking to see if such information has become outdated. Furthermore it is certainly not a duplicate of questions relating specifically to C#, as these are two different (albeit similar) languages. The difference between classes and structures is language-dependent, as can be demonstrated by VB.NET and C++.
In Visual Studio 2012, when creating a new VB.NET file, you get options for Module and Class, among other things, but there is no option for Structure. For instance:
If you simply select to add a new item, then the much more complete menu doesn't list it either:
This seems like an awfully big oversight, especially when there are meaningful differences between classes and structures in VB.NET, so I'm certainly suspicious that it's not really an oversight at all.
Are structures a deprecated practice now? Has the language been revised in some way that has made the difference between a structure and a class much more meaningless? Is there any technical or widely-held convention that I am unaware of here? Or is it just an oversight after all? Thanks.
EDIT
To make a long story short, my understanding is that, among one or two other things, structures tend to be more efficient for smaller amounts of code, and classes tend to be more efficient for larger amounts. This is because of differences between they ways that their memory is managed. Even though a lot of people always think in terms of classes in a language-agnostic kind of way, I thought there was a practice among fluent VB.NET developers to use structures as well.
No, structures are not deprecated. They have just never been on the Add Item list.
Which is probably because people haven't been willing to reserve a whole file for a single structure, preferring to put them in classes and modules. But you can if you want.
If you are concerned with class vs structure differences, you probably want to see Structs versus classes.
Just to add some more information... The type that you choose from the "Add" dialog only affects the initial template you get in the editor. It is perfectly valid to add a Class file, then edit it to turn it in to a structure, form, or even a module. Typically if you want to create something that isn't in the list you would choose "Code File" to get a blank document to customize as you want.
You can even create your own templates to add to that list. If you find yourself wanting to add a template for a structure you can do it fairly easily.
Here are some basic instructions on how to do that.
http://msdn.microsoft.com/en-us/library/tsyyf0yh.aspx
Some structure types like List<T>.Enumerator are used essentially the same way as objects, but a more common usage case for structures is as simple aggregate types which hold some data for the use of other types. The behavior of a type like KeyValuePair<TKey, TValue> is simply "Key and Value are properties of type TKey and TValue, which hold whatever outside code asked them to hold." While some companies' policies may require that every type reside within its own file and have its own associated documentation package, placing utility structures into a file with a package's static utility functions, static constants, etc. may make more sense than splitting them into separate files, especially if they don't have any substantial logic of their own.
Nothing is preventing a programmer from placing a structure into a file by itself, but the usage case was not considered sufficiently frequent to justify a special template for that purpose.
What is the best practice for having many different menus/screens/forms in a visual basic program? Would it be to just make a new form for each menu or screen that I want? Or are there other better options?
I am not trying to make this overly complicated, I have a group project to work on and we all have different skill levels. That said it has peaked my curiosity so I figured it wouldn't hurt to ask before I got started.
I can see this question being closed pretty quickly as being too open ended so allow me to get in my key gripe on this before that happens... no .Visible property for TabControl pages? Seriously, Microsoft??
Which brings me to the key point. If the forms are in some way related but not necessarily identical I prefer to use a single form with different tabs, despite that glaring shortcoming in the control. (Which you don't have to look far to find workarounds for on SO, but a workaround is still a workaround.) Dynamically manipulating controls at run time is another side of this coin, though one that I tend to use more rarely... but that's just a personal thing.
In a recent application, for instance, I had lists of several types of objects. They were related, but performed quite different functions and the user wouldn't really need to look at more than one list at once. As a result I used one form with a tab for each object list to keep the users' display less cluttered.
Similarly when doing a GL app recently I had the journal header and journal line entries (which go to different tables in the back-end database) in separate parts of the one form. On the other hand asset creation was sufficiently different that I created a different form, despite the creation process sharing some of the underlying data. (That is, journal line data.)
I don't believe in the concept of "best practice" because what's a good practice in one situation may be a very bad one in another. However the "rules of thumb" that I use are:
- Keep the number of forms to a minimum to keep overhead low and reduce maintenance BUT
- If there is no logical "tie" between two functions, don't be afraid to make a new form because trying to maintain one form which performs 7 different roles is a guaranteed path to madness and frustration, especially if you break something inadvertently.
Yes, the two rules conflict, but in a way I see this aspect of design as being akin to database normalisation; there's a sweet spot between over-normalising (a separate form for each and every display) and under-normalising (trying to shoe-horn too many unrelated functions into one form). At the very least the rules always give me pause to think "do I need this form, or does it relate to something that I've already done?"
And the third rule of thumb is, obviously... always look at it from the point of view of your user. Are they going to feel like you're bouncing them around too much? Do all of the forms share a look and feel and, more importantly, control layout so that they always know where to find something?
All of these things will vary from app to app, and there's never one size that will fit all IMHO.
In my case, when I am dealing with multiple forms, I use MDI Parent Form to avoid multiple items in the windows task bar.
Another unusual solution is to set each forms ShowInTaskbar property to false.
In declaring an array in VB, would you ever leave the zero element empty and adjust the code to make it more user friendly?
This is for Visual Basic 2008
No, I wouldn't do that. It seems like it might help maintainability, but that's a very short-sighted view.
Think about it this way. It only takes each programmer who has to understand and maintain the code a short amount of time to get comfortable with zero-indexed arrays. But if you're using one-based arrays, which are unlike those found in almost all other VB.NET code, and in fact almost every other common programming language, it will take everyone on the team much longer. They'll be constantly making mistakes, tripping up because their natural assumptions aren't accurate in this one special case.
I know how it feels. When I worked in VB 6, I loved one-based arrays. They were very natural for the type of data that I was storing, and I used them all over the place. Perfectly documentable here, because you have an explicit syntax to specify the upper and lower bounds of the array. That's not the case in VB.NET (which is a newer, but incompatible version of the Visual Basic language), where all arrays have to be zero-indexed. I had a hard time switching to VB.NET's zero-based arrays for the first couple of days. After that initial period of adjustment, I can honestly say I've never looked back.
Some might argue that leaving the first element of every array empty would consume extra memory needlessly. While that's obviously true, I think it's a secondary reason behind the one I presented above. Good developers write code for others to read, so I commend you for considering how to make your code logical and understandable. You're on the right path by asking this question. But in the long run, I don't think this decision is a good one.
There might be a handful of exceptions in very specific cases, depending on the type of data that you're storing in the array. But again, failing to do this across the board seems like it would hurt readability in the aggregate, rather than helping it. It's not particularly counter-intuitive to simply write the following, once you've learned how arrays are indexed:
For i As Integer = 0 To (myArray.Length - 1)
'Do work
Next
And remember that in VB.NET, you can also use the For Each statement to iterate through your array elements, which many people find more readable. For example:
For Each i As Integer In myArray
'Do work
Next
First, it is about programmer friendly, not user friendly. User will never know the code is 0-based or 1-based.
Second, 0-based is the default and will be used more and more.
Third, 0-based is more natural to computer. From the very element, it has two status, 0 and 1, not 1 and 2.
I have upgraded a couple of VB6 projects to vb.net. To modify to 0-based array in the beginning is better than to debug the code a later time.
Most of my VB.Net arrays are 0-based and every element is used. That's usual in VB.Net and code mustn't surprise the reader. Readability is vital.
Any exceptions? Maybe if I had a program ported from VB6, so it used 0-based arrays with unused initial elements, and it needed a small change, I might match the pattern of the existing code. Least surprise again.
99 times out of 100 the question shouldn't arise because you should be using List(Of T) rather than an array!
Who are the "users" that are going to see the array indexes? Any good developer will be able to handle a zero-indexed array and no real user should ever see them. If the user has to interact with the array, then make an actually user-friendly system for doing so (text or a 1-based virtual index or whatever is called for).
In visual basic is it possible to declare an array starting from 1, if you find inconvenient to use a 0 based array.
Dim array(1 to 10) as Integer
It is just a matter of tastes. I use 1 based arrays in visual basic but 0 based arrays in C ;)
Someone I know wants to use diconnected recordsets in an application. To me it sounds like if I have a ORM tool there would really be no need to even touch disconnected recordsets. The way I understand it with ORM the ORM takes care of not hugging connections for unnecessarily long amounts of time, solving the need for a disconnected recordset. Is there an instance in which you would still want to use a disconnected recordset?
A fabricated ADO recordset can be a good choice of container object for data, as an alternative to a VBA Type (struct), Collection, Dictionary, etc i.e. strongly data typed nullable fields** with built-in support for filtering, sorting, searching, output to formatted text/xml/array, paging , cloning, etc. A fabricated ADO recordset is disconnected by definition.
Perhaps this isn't quite what you had in mind but it is a valid answer to your question i.e. an example of when you would still want to use a disconnected recordset, even though you have an ORM.
** Similary, ADO Parameter objects are a usual alternative for the Variant type in that, unlike VB intrinsic types, they can be both strongly data typed and nullable.
I'd consider using a recordset in small "assemble and forget" applications or when you have simple reporting needs like read-only grid views.
That includes any application where it feels like the quickest thing you can do, and you don't see a reason it will change later on.
However, if you are going to build a slightly advanced, maintainable, robust application, with business logic and the like, don't go with recordsets.
But sure, there's still use for it..