Page 1 of 2 12 LastLast
Results 1 to 40 of 51

Thread: Visual Basic Limitations

  1. #1

    Thread Starter
    Member
    Join Date
    Jan 2013
    Posts
    50

    Visual Basic Limitations

    I'm new to VB - I've been learning C++ for a few months (painfully) - and decided to learn VB on the side, to get faster results.
    I know that you can do far more in C++, but I'm not exactly sure where the line is drawn.

    If you have a free minute, I'd love to know what all is capable with VB.
    Please tell me about some of the programs you've made in VB - I'd love to hear about your projects.

    Any insight for a noob would be greatly appreciated!
    Last edited by codenewbie; Jan 24th, 2013 at 01:02 PM.

  2. #2
    Karen Payne MVP kareninstructor's Avatar
    Join Date
    Jun 2008
    Location
    Oregon
    Posts
    6,684

    Re: Visual Basic Limitations

    From my perspective there is not much you cannot do with VB.NET. Granted when you get into gaming and graphics C when done properly usually is faster then VB.NET. How far can you push VB.NET, pretty dang far yet one has to ask, just because I can, should I?, same with any development language.

    There has to be a balance between how quickly a product can be brought to market and how well it performs to customer specifications. If needed you can meld C Sharp and VB.NET into a solution if in a operation C is faster. Another thought is knowing how to code a particular section of code, for instance one might choose LINQ instead of conventional assertion, for/next, if statements etc. or knowing the proper container to house data can make all the difference in the world.

  3. #3

    Thread Starter
    Member
    Join Date
    Jan 2013
    Posts
    50

    Re: Visual Basic Limitations

    Kevin -

    Thank you for taking the time to reply to my thread - Im still in the learning process, so I greatly appreciate your input!

    You seem to know quite a bit about the program - may I ask if you could point me in the direction of some good tutorials?

  4. #4
    eXtreme Programmer .paul.'s Avatar
    Join Date
    May 2007
    Location
    Chelmsford UK
    Posts
    25,464

    Re: Visual Basic Limitations


  5. #5
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    8,598

    Re: Visual Basic Limitations

    Writing drivers is something that can be done with C but not with VB.Net.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  6. #6
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    38,989

    Re: Visual Basic Limitations

    VB code will be slower, but you generally won't know. The only time you would care about the difference in speed, since it is pretty minor, is for those rare programs where you have to squeeze out every last cycle. This basically only happens in games and graphics coding, and only the very most intensive of those, since XNA and other things expose the graphics tools to VB.NET (and C# of course). Basically, there are only a few reasons why you would choose C++ over one of the .NET languages, but learning C++ is still a good idea. For one thing, the Object Oriented principles are the same throughout, so nothing is lost there, and the syntax of C/C++ has been incorporated into so many languages that being able to read it will serve you well in nearly any language.
    My usual boring signature: Nothing

  7. #7

    Thread Starter
    Member
    Join Date
    Jan 2013
    Posts
    50

    Re: Visual Basic Limitations

    Thank you so much for your input!
    If anyone else has anything to add, I would love to hear it!

  8. #8
    Karen Payne MVP kareninstructor's Avatar
    Join Date
    Jun 2008
    Location
    Oregon
    Posts
    6,684

    Re: Visual Basic Limitations

    Another thing when considering performance, understanding using multiple threads can make a difference in the responsiveness of an application. This is not to say using multiple threads on all applications but instead as needed. Even then you might consider alternate solutions. For instance you want to load 100,000 rows from a back-end database with 20 columns. Perhaps a better solution is to load data on-demand i.e. using a DataGridview use virtual mode or using user criteria to load data.

  9. #9
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    38,989

    Re: Visual Basic Limitations

    The performance difference between VB and C++ is sufficiently minor that in almost every case you can find a way to improve your algorithm to cause a greater performance boost than changing languages would be able to provide. I, personally, like to count cycles, and have made many measurements on simple code constructs to see which is faster. By following such practices it is possible to get the best performance out of VB. For those small things, such as individual for loops, calculations, and the like, C++ would be faster. However, those are the details. To make any really big gains in performance you always have to rethink the problem at a much larger scale. Multithreading would be one possible approach, where it is appropriate.

    My point is that the performance difference between C++ and VB generally doesn't matter, because a poor algorithm in C++ is always going to be much worse than a good algorithm in .NET. So the quality of the design matters more than the language in most cases (device drivers are one exception to that, but not many people write them). Finally, the quality of the design really doesn't have anything to do with the language (at least not between .NET and any C language), but it will be generally quicker to try different alternatives in VB than in C++.
    My usual boring signature: Nothing

  10. #10

    Thread Starter
    Member
    Join Date
    Jan 2013
    Posts
    50

    Re: Visual Basic Limitations

    Thank you - everyone that has replied has been a great help!

    If any of you have a free minute - would you be willing to tell me about some of the larger projects you've made in vb?
    Just so I can get a better idea as to what exactly is possible?

    Thank you so much!

  11. #11
    Smooth Moperator techgnome's Avatar
    Join Date
    May 2002
    Posts
    34,532

    Re: Visual Basic Limitations

    I've worked on enterprise-level applications... one was a Customer Relationship Management (CRM) system that also did billing... Of the three major systems I've worked on, this one was probably the simplest...
    I've also worked on another system that tracked costs and budgets for construction projects... that was a fun one... probably the most complex one based on the sheer volume of data... and that it was not only a multi-layered app, but it was also a true n-tier app.
    The system I currently work on now is another CRM app. It is a multi-tiered, multi-layered app ... and is web-based... although the web rendering is done by the application's platform that we've developed. Also, what I do is design, develop, and implement customizations as opposed to developing the base product, so most of the work I do is SQL-based, but a fair amount of it is still working with server-side components in VB.NET. Even still, the platform upon which the system is built was written in .NET.

    Then there's also Visual Studio, parts of it were written in VB.NET and C# and XAML ...

    I'm sure there's a lot of apps out there written in .NET.

    -tg
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.*
    * I also don't respond to friend requests. Save a few bits and don't bother. I'll just end up rejecting anyways.*
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *

  12. #12
    PowerPoster
    Join Date
    Feb 2012
    Location
    West Virginia
    Posts
    14,205

    Re: Visual Basic Limitations

    Without reading all of the posts here I am sure that by now you have gotten the idea that there is a lot you can do with VB. It would be easier to list what you can't do than what you can as that would be a much shorter list.

    One of the biggies is that programs written in C++ can be compiled to run on other operating systems other than Microsoft.

    To date I have had to write 3 programs which could not be written in a form of VB, This was due to the fact that 1 required specific data structures that could not be duplicated in the versions of Basic at the time and another required that it be written in C in order to link in with another project and the third was a driver.

    Every other project i have been tasked with could be done in some form of Basic or VB though in a few cases I have used C# or C++ just for the experience.

  13. #13
    Smooth Moperator techgnome's Avatar
    Join Date
    May 2002
    Posts
    34,532

    Re: Visual Basic Limitations

    "1 required specific data structures that could not be duplicated in the versions of Basic at the time" -- I got around that by developing a class in C++ that held the structure needed... then referenced it and did the rest in VB.

    -tg
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.*
    * I also don't respond to friend requests. Save a few bits and don't bother. I'll just end up rejecting anyways.*
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *

  14. #14
    PowerPoster
    Join Date
    Feb 2012
    Location
    West Virginia
    Posts
    14,205

    Re: Visual Basic Limitations

    In my case that would not have worked either. VB as we know it was not an option. I ended up writing 2 programs 1 very small program in Turbo Pascal which converted the data structure <> the 3rd party source program. The main program I wrote in VBDos. Keep in mind this was a long time ago VB4 had not been released yet. The dominant OS was still Dos and I was running OS/2

    The program in question was linked into a BBS Door and was an addon to another game which was written I think in Pascal.

    For those who are not familiar with VBDos it was [for lack of a better comparison] Quick Basic 4.5 with a visual designer component.

  15. #15
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    38,989

    Re: Visual Basic Limitations

    I can't talk about the most complex one I have worked on in VB, because nobody knows I'm doing it, and when they find out...well, some people may be upset...or not, it's hard to say. It's not all that big, really, but it is massively complex and thoroughly entertaining, which is why I'm writing it. If it works out, it will be pretty valuable. If it doesn't...at least we'll know that the problem can't be solved. That may strike people as an odd statement, as it kind of sounds like I'm saying that I can prove a negative, but that's not the case. There are people who really want software in a theoretical way, but when they actually USE the software, they find out that the benefits they can get from having the data isn't worth the time needed to enter the data. The main point of this project, aside from me being able to try out a bunch of new things and have fun, is to get people to talk honestly about what they want. One group wants a bunch of data as long as somebody else enters it. The people who have to enter it, may or may not be willing to enter it. This program will be like pouring water onto some metalic sodium: The result is likely to be highly entertaining, somewhat damaging, and most likely will also be brighly, though briefly, illuminating.
    My usual boring signature: Nothing

  16. #16
    King of sapila
    Join Date
    Oct 2006
    Location
    Greece
    Posts
    6,597

    Re: Visual Basic Limitations

    Got you Shaggy.You are writing the new Facebook++ . Easy catch.
    Now on C vs .net. Well the initial core coding of .net was in C so by default C is better in any possible way a star fighter could think of.
    I could dare to say that .net is not even a real programming language but that is a discussion i cannot make because i am going to bed.
    Having said that, i would only use C if i was forced with a gun but like it or not C -- C++ is the core of everything (not including assembly of course).
    ἄνδρα μοι ἔννεπε, μοῦσα, πολύτροπον, ὃς μάλα πολλὰ
    πλάγχθη, ἐπεὶ Τροίης ἱερὸν πτολίεθρον ἔπερσεν·

  17. #17
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    8,598

    Re: Visual Basic Limitations

    Quote Originally Posted by sapator View Post
    I could dare to say that .net is not even a real programming language....
    Interesting....I've always thought of VB.Net as a fancy scripting language. What we do is actually scripting the .Net framework. However, Platform Invoke makes me hesitate to fully commit to the consideration of VB.Net as a scripting language as it is capable of tapping power beyond the native capabilities of the framework with that system making it as potentially as powerful as C/C++. Scripting languages in general cannot operate outside the constraints of their execution engine and its available keywords, functions and classes(if applicable).
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  18. #18
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    38,989

    Re: Visual Basic Limitations

    Quote Originally Posted by sapator View Post
    Got you Shaggy.You are writing the new Facebook++ . Easy catch.
    Not me. I'm more into anti-social media. No, my subject is much more fishy than that.
    My usual boring signature: Nothing

  19. #19
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    38,989

    Re: Visual Basic Limitations

    Quote Originally Posted by Niya View Post
    Interesting....I've always thought of VB.Net as a fancy scripting language. What we do is actually scripting the .Net framework. However, Platform Invoke makes me hesitate to fully commit to the consideration of VB.Net as a scripting language as it is capable of tapping power beyond the native capabilities of the framework with that system making it as potentially as powerful as C/C++. Scripting languages in general cannot operate outside the constraints of their execution engine and its available keywords, functions and classes(if applicable).
    I don't think that .NET should be considered a scripting language. After all, the JIT compiler gives you native code, and it only runs once. After that, you have just the native code until you invalidate it by some means. It certainly operates within some constraints, but show me a language that does not? The constraint for .NET is Windows and the Windows API and execution model. C++ written for Windows has the same constraints. Furthermore, virtually no C++ code operates outside of the constraints of the libraries you include. The real difference was that .NET was designed with the idea that different JIT compilers could turn the IL into native code on a variety of platforms, which is something VB6 and C++ never could do. In theory, C++ is generic enough that it should be possible to compile the source against a variety of platforms, but only by running different compilers, and in practice it never really worked for all but trivial programs. The idea behind .NET was that, once you had the IL, it would run correctly on any platform for which there was a JIT compiler. In that way, it had the same promise as Java. As it turned out, neither one truly lived up to their promise, and both operate as promised only with some serious exceptions.
    My usual boring signature: Nothing

  20. #20
    Super Moderator FunkyDexter's Avatar
    Join Date
    Apr 2005
    Location
    An obscure body in the SK system. The inhabitants call it Earth
    Posts
    7,900

    Re: Visual Basic Limitations

    No, my subject is much more fishy than that.
    Fishing .Net?

    Not sure if the OP's still reading but I'll throw in my two pennorth anyway. As the size complexity of the app increases the high level capabilities of a language like .Net become more desirable. Because they abstract away the nitty-gritty they free you up to concentrate on the business complexity and churn bigger volumes of functionality quicker.

    Low level languages like C are better for solving small, discrete problems where you really [I]want[I] to understand the nitty-gritty, usually becasue you want to make it really preformant.
    The best argument against democracy is a five minute conversation with the average voter - Winston Churchill

    Hadoop actually sounds more like the way they greet each other in Yorkshire - Inferrd

  21. #21

    Thread Starter
    Member
    Join Date
    Jan 2013
    Posts
    50

    Re: Visual Basic Limitations

    This thread quickly went sideways lol.
    Lets keep talking about the projects that you have made or are currently working on.
    Just a brief description of what the program does.

    And none of Shaggy's TOP SECRET stuff... I want to actually hear what you are working on
    Last edited by codenewbie; Jan 24th, 2013 at 01:00 PM.

  22. #22
    Super Moderator FunkyDexter's Avatar
    Join Date
    Apr 2005
    Location
    An obscure body in the SK system. The inhabitants call it Earth
    Posts
    7,900

    Re: Visual Basic Limitations

    Lets keep talking about the projects that you have made or are currently working on
    Well typically I've worked on business apps. CRM systems, marketting systems, booking systems, that kind of thing. For that stuff .Net is perfect because I want to concentrate on the business rules. I don't care, for example, what part of the memory I'm addressing at a given point in time.

    If I were working at a software house that produced software components for other developers to use, for example, I'd probably want to use something low level like C because, while the problems I was solving might be quite small, I'd want to be solving them in the most efficient way possible.

    Generally high level problems call for a high level language. Low level problems call for a low level one.
    The best argument against democracy is a five minute conversation with the average voter - Winston Churchill

    Hadoop actually sounds more like the way they greet each other in Yorkshire - Inferrd

  23. #23

    Thread Starter
    Member
    Join Date
    Jan 2013
    Posts
    50

    Re: Visual Basic Limitations

    Thank you for the replies - lets keep this going!

    What programs have you made in VB?
    Could be for professional or personal use - I just want to hear about them.

  24. #24
    PowerPoster
    Join Date
    Feb 2012
    Location
    West Virginia
    Posts
    14,205

    Re: Visual Basic Limitations

    I mostly work now with inventory and tracking systems, much of my coding is for Windows CE/Mobile devices but there is usually a piece or two on the PC as well.
    The program I mentioned earlier was actually the first program I had written where I managed to sell more than one copy. No big deal really but I was happy that I was able release it as shareware over Fido Net [days before the Internet] and actually got paid for 100 copies.

  25. #25
    PowerPoster Jenner's Avatar
    Join Date
    Jan 2008
    Location
    Mentor, OH
    Posts
    3,712

    Re: Visual Basic Limitations

    Most of my programming is industrial related. For my company which sells industrial equipment, I've written many applications to better integrate shop-floor control how we want it done. One program I wrote lets you scan a barcode on a sales order, which then lists the major pieces of industrial equipment that are on that order. The user then scans serial-number barcodes on the actual "ready-to-ship" equipment to "assign" that specific piece of equipment to that sales order. The system then prints out some additional labels which are attached to the equipment and shipping box. It's one of two labeling programs I wrote, the other is the one that generates the aforementioned serial-number barcodes.

    Another project was a data-miner for our ERP system that accesses it's database directly and builds reports with very specific, often complex criteria from multiple data tables. Some are then sent as output to printable reports, others are ported to on-screen manipulation controls so the data can be further analyzed by the user.

    The biggest project I ever did was a program that served as the control system to a large piece of industrial OEM equipment we used to sell for mixing ink and colorants. Besides it's major functions as a database of ink formulas and the ability to dispense those formulas once hooked up to the right equipment, it needed to be industrially hardened against customers trying to do odd things with it, needed to have an actual user-friendly installer, needed to comply to any version of Windows it could be installed on, needed to be crash-resistant and impervious to erroring due to things like "sudden loss of computer power" since these were going to be "in the field". These all may not seem like big things; until you have to deal with them, and for a small, solo programmer who's never had their programs exist outside a controlled environment, they're a big deal.

    I used to do things like "save configuration files" with a simple .Write command overwriting the existing with the new one, until I got a call from a customer who had a power outage/computer crash right when it was doing so and thus losing his data! Now, I write a new configuration to a temp file in the temp directory, then copy the existing configuration file to the temp directory, finally, I copy the new file onto the old one in the data directory. If anything fails in loading the new configuration file because something got corrupt, I have it read in the copy in the temp directory, or if that fails, the copy of the original that's also there. My "load configuration" routine also checks for things such as empty files, improper XML, and missing required fields now. I had no idea something as stupidly simple as "saving a file" could become so complex; but I never had a tech-call about a crashed configuration file again!

    All these "little things" begin to add up, and the more you figure out how to handle them, the better a programmer it makes you. Next thing you know, you start doing what the C++ guys do, you start saving your little code bits for use in other projects and begin building up a little "toolbox" of handy routines. I've got tons of them now for doing all sorts of things including: reading and writing configuration files, accessing databases, reading streaming serial port data, handling user accounts and licensing, reading a barcode scanner with a low-level windows hook and a complete, user-editable report handler.
    My CodeBank Submissions: TETRIS using VB.NET2010 and XNA4.0, Strong Encryption Class, Hardware ID Information Class, Generic .NET Data Provider Class, Lambda Function Example, Lat/Long to UTM Conversion Class, Audio Class using BASS.DLL

    Remember to RATE the people who helped you and mark your forum RESOLVED when you're done!

    "Two things are infinite: the universe and human stupidity; and I'm not sure about the universe. "
    - Albert Einstein

  26. #26
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    38,989

    Re: Visual Basic Limitations

    One program that I built and maintain deals with managing certain fish data, but everything I have written for work falls into that category. As it turns out, any science organization will generate a VAST quantity of data. As long as their studies are over in a year, or two, then they can use Excel. Once they get into long term monitoring, the data begins to get away from them. Therefore, there is an unusually high need for programmers to support science, but it's a need that is usually ignored. The result is that anybody who has a capacity, however minimal, and interest in programming will get sucked into it. I probably can't accurately count the number of programs I have currently in use managing various things around the department. As I write this, I keep adding to the list. The majority of them wouldn't be considered large by anybody, yet they are fairly vital to the processes they are used in, and they are almost entirely taken for granted.

    From a programming perspective, this is a pretty good situation. I get to work on very diverse problems, most of which are finished in under a month, and all of them are barely related to one another. Furthermore, people I work for on these things are quite grateful, which compensates for the low pay (well, that plus the outrageous flexibility in hours and working conditions, which is worth a LOT to me).

    The diversity is really pretty high. One program that I wrote and presented to a group of biologists, used a genetic algorithm to evolve mathematical equations to fit complex curves to complex data. Effectively, it was a non-linnear, polynomic, multi-variate regression analysis engine, but I didn't figure that out until after I had finished it. You would put in some pattern, such as fish returning to some location, then enter all the data that you felt caused the pattern...then let it run for a couple days. The result would be an equation that fit the variables to the pattern, along with some sensitivity analysis that gave some metrics on how important each variable was to each equation.

    The thing was too dangerous to live, so I shelved it. Give a bunch of biologists a tool to create models, and they will create models, whether the models are warranted or not, and this was dead easy to use. It was also a good lesson in efficiency. The first version didn't have Option Strict ON, and I used a lot of implicit conversions. When I realized this, and fixed it, the time to complete dropped from three days to two, which shows just how bad implicit conversions are.

    Another, really odd, program I wrote will take a string and create a pattern out of the bytes (in ASCII). The point was to design my back yard, which is now a message in binary written in 1'x1' paving stones. The program allowed me to enter the number of total bricks I had to work with in rows and columns (it was far from square), then I would type various strings into a textbox, and the program would show the pattern of bricks, along with the number needed of each color. I've always been annoyed by bathroom floors, and other tiled floors, where the tiles are just random. Random is a cop-out for those who aren't artistic, but if you can't come up with a nice pattern, then at least you should encode a message into the tiles to fire up the geeks in the world.

    I think the point is that .NET really allows you to do whatever you want with few exceptions.
    My usual boring signature: Nothing

  27. #27
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    8,598

    Re: Visual Basic Limitations

    Quote Originally Posted by Shaggy Hiker View Post
    I don't think that .NET should be considered a scripting language. After all, the JIT compiler gives you native code, and it only runs once. After that, you have just the native code until you invalidate it by some means. It certainly operates within some constraints, but show me a language that does not? The constraint for .NET is Windows and the Windows API and execution model. C++ written for Windows has the same constraints. Furthermore, virtually no C++ code operates outside of the constraints of the libraries you include. The real difference was that .NET was designed with the idea that different JIT compilers could turn the IL into native code on a variety of platforms, which is something VB6 and C++ never could do. In theory, C++ is generic enough that it should be possible to compile the source against a variety of platforms, but only by running different compilers, and in practice it never really worked for all but trivial programs. The idea behind .NET was that, once you had the IL, it would run correctly on any platform for which there was a JIT compiler. In that way, it had the same promise as Java. As it turned out, neither one truly lived up to their promise, and both operate as promised only with some serious exceptions.
    Your points do have merit however, I was thinking more along the lines of the number of abstractions between you and the OS. You see, not long after I moved to .Net, it struck me that if it didn't have Platform Invoke, the .Net environment would have been completely sealed off from the OS. Every thing would be 'managed' by the framework using its abstractions. The OS, Windows in particular, is really just a collection of APIs written in C so when you use a language like C or C++ you are doing stuff the way windows really does it so you aren't constrained by abstractions.

    Think about this: Imagine how the OS creates a window. Internally, Windows would use the CreateWindow API. It uses quite a few parameters that use different types like pointers, char arrays and such. Now because they were written in C to begin with, you can use this API to its fullest in a language like C. You would be able to use any data type its parameters demand. You're unconstrained. Now imagine .Net without Platform Invoke. There would be no way to create a window unless the framework provided a managed API to do so and there is no guarantee that it would provide all the parameters actually used by the OS. Even with Platform Invoke, you're still dependent on .Net having a way to marshal its abstractions to something the actual API can understand, like marshalling a String as a pointer to a char array. A String doesn't mean anything to the OS. Its a managed abstraction. This is what I'm talking about. The truth of how the OS really works is hidden by the abstractions of the managed environment. Its really not unlike a scripting language like JavaScript. You can only interact with OS so far as allowed by the scripting environment through whatever abstractions they provide.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  28. #28
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    8,598

    Re: Visual Basic Limitations

    On the subject of whats possible in .Net: I've recently written a program(well a pair actually, client and server) that allows someone to upload and download files between two computers over a network or the internet using TCP/IP as the basis for communication.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  29. #29
    PowerPoster
    Join Date
    Feb 2012
    Location
    West Virginia
    Posts
    14,205

    Re: Visual Basic Limitations

    Quote Originally Posted by Niya View Post
    On the subject of whats possible in .Net: I've recently written a program(well a pair actually, client and server) that allows someone to upload and download files between two computers over a network or the internet using TCP/IP as the basis for communication.
    I do a lot of this, mostly to transfer data or files to/from PC<>Mobile Device. The first version was VB6 on the PC and Embedded VB3 on the mobile device, later I moved on to the .net platform.

    I am currently working on the Server program in an attempt to turn it into a windows service. So far I have ran into some threading issues that I do not quite understand but in general it is going well.

  30. #30
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    38,989

    Re: Visual Basic Limitations

    I got sidetacked from a series of programs that was a robot brain. The different parts of the brain were spread across three or four computers, each with certain tasks it had to perform based on the number of CPU cores. The programs all used UDP to communicate between all other brain components, and the system could scale up easily to take advantage of more CPU cores as they became available.

    I think we've largely covered the idea that there are no substantial limits on VB.

    @Niya: I think my view is that the term "scripting language" suggests an interpreted language that works only within the context of a single program. I pretty much agree with the distinction you make, I just would have used a different term. VB is a higher level language, while C/C++ are considered intermediate level or even low level (though ASM is occasionally considered to be the only true low level language). Higher level languages work at a higher level of abstraction, which generally makes them easier to work with. In truth, pretty much every program most of us write is hosted in some way. While you can work more easily directly with the Windows API in C/C++ without the abstractions of the framework, you are still working with something like the framework. The framework is the same essential category of thing that includes the Windows API, depending on how you defined the categories. In both cases, they are a way of hooking code into a larger environment such that the ultimate application runs as part of a larger system. The rest just seems like details, to me.
    My usual boring signature: Nothing

  31. #31
    Cumbrian Milk's Avatar
    Join Date
    Jan 2007
    Location
    0xDEADBEEF
    Posts
    2,448

    Re: Visual Basic Limitations

    My main project last year was a prototype system for tracking bird movement around offshore wind turbines.
    During daylight hours the system acquires camera data at ~128 mb/sec this is then analysed and compressed before transmitting over a 5 GHz PTP bridge back to a ground station 18 km away. The data is then periodically couriered back to base for more analysis the results of which are shown to a group of human reviewers who attempt to identify the bird species. Finally once verified 3D bird paths are generated and we have evidence of whether key bird species are exhibiting avoidance behavior around turbine blades.

    I wrote all the acquisition and the compression code in C++. The code makes heavy use of SIMD instructions and dirty bit tricks over multiple threads. I feel NET would really struggle with the bandwidth required for this. I did however use managed C# for pretty much everything else from hardware control on the remote station to the pretty GUI application for the reviewers. The C# code could all be done with VB without any problems.

    I never thought that a programming job would get me trained up to work on offshore turbines.
    W o t . S i g

  32. #32

    Thread Starter
    Member
    Join Date
    Jan 2013
    Posts
    50

    Re: Visual Basic Limitations

    Thank you for your replies!

    It seems like many of you are solo programmers.
    May I ask, what was the price tag you gave to your client with some of your associated programs?

    I'd like to sell some of the ideas I have, and understand the pricing is very dependent on the functionality of the program - but I'd like to get a rough idea as to what custom software costs.
    Any input/advice here would be greatly appreciated.

  33. #33
    PowerPoster
    Join Date
    Feb 2012
    Location
    West Virginia
    Posts
    14,205

    Re: Visual Basic Limitations

    Pricing varies greatly, I pretty much do not bother for anything less than $250, Most project I work on are not to large and fall in the $500 - $2500 range though I have did a few that were over $10,000 and some over $20,000

  34. #34
    eXtreme Programmer .paul.'s Avatar
    Join Date
    May 2007
    Location
    Chelmsford UK
    Posts
    25,464

    Re: Visual Basic Limitations

    Quote Originally Posted by codenewbie View Post
    Thank you for your replies!

    It seems like many of you are solo programmers.
    May I ask, what was the price tag you gave to your client with some of your associated programs?

    I'd like to sell some of the ideas I have, and understand the pricing is very dependent on the functionality of the program - but I'd like to get a rough idea as to what custom software costs.
    Any input/advice here would be greatly appreciated.
    I'm in the same boat, but freelance custom software prices + full time employment are 2 different cases

  35. #35

    Thread Starter
    Member
    Join Date
    Jan 2013
    Posts
    50

    Re: Visual Basic Limitations

    Quote Originally Posted by DataMiser View Post
    Pricing varies greatly, I pretty much do not bother for anything less than $250, Most project I work on are not to large and fall in the $500 - $2500 range though I have did a few that were over $10,000 and some over $20,000
    What is a $250 software to you?
    What is a $2500 software to you?
    What is a $10,000 software to you?

    Your prices are all over the place, and its understandable, as no two software applications are the same... But what makes those programs valued at the prices you gave them?

    I understand my questions was incredibly vague - just trying to get some rough ideas.

    so... "For a software that can do X, I charge $250", or "For a software that can do X, Y and Z, I charge $2500+".
    I'm not looking for the recipe to your secret sauce - I'm just trying to get an idea as to how you would price a particular project.

  36. #36

    Thread Starter
    Member
    Join Date
    Jan 2013
    Posts
    50

    Re: Visual Basic Limitations

    Quote Originally Posted by .paul. View Post
    I'm in the same boat, but freelance custom software prices + full time employment are 2 different cases
    I'm looking for freelance prices..
    I've got a day job, and plan on keeping it.
    I want to hustle software on the side.
    What kind of cash are we looking at?

  37. #37
    PowerPoster Nightwalker83's Avatar
    Join Date
    Dec 2001
    Location
    Adelaide, Australia
    Posts
    13,344

    Re: Visual Basic Limitations

    Quote Originally Posted by sapator View Post
    I could dare to say that .net is not even a real programming language
    You are correct there but only because .Net is a framework and not a language.
    when you quote a post could you please do it via the "Reply With Quote" button or if it multiple post click the "''+" button then "Reply With Quote" button.
    If this thread is finished with please mark it "Resolved" by selecting "Mark thread resolved" from the "Thread tools" drop-down menu.
    https://get.cryptobrowser.site/30/4111672

  38. #38
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    38,989

    Re: Visual Basic Limitations

    What I would caution about hustling software on the side is this: How do you feel about support?

    I did a little of that, but found that I'm way too soft to make a habit of it. I kind of became free tech support, in that case. If you were selling the software, then it would be a strictly business deal, but then you'd have to be all business about it. I don't think I'd be good at that.
    My usual boring signature: Nothing

  39. #39

    Thread Starter
    Member
    Join Date
    Jan 2013
    Posts
    50

    Re: Visual Basic Limitations

    Quote Originally Posted by Shaggy Hiker View Post
    What I would caution about hustling software on the side is this: How do you feel about support?

    I did a little of that, but found that I'm way too soft to make a habit of it. I kind of became free tech support, in that case. If you were selling the software, then it would be a strictly business deal, but then you'd have to be all business about it. I don't think I'd be good at that.
    I see where you are coming from.
    I think its just a matter of being smart about your contract with the client.
    Why not approach it like the bigger software companies - offering free support for say 90 days or so, then after that you charge them for your time.

    You can make anything worth your while if you set the terms up front, and the client agrees...
    Thats how I plan to approach it.

    If you dont dot your i's and cross your t's, the client will find loop holes - and abuse them.
    I have found this out the hard way on previous endeavors..

  40. #40
    eXtreme Programmer .paul.'s Avatar
    Join Date
    May 2007
    Location
    Chelmsford UK
    Posts
    25,464

    Re: Visual Basic Limitations

    Quote Originally Posted by codenewbie View Post
    I see where you are coming from.
    I think its just a matter of being smart about your contract with the client.
    Why not approach it like the bigger software companies - offering free support for say 90 days or so, then after that you charge them for your time.

    You can make anything worth your while if you set the terms up front, and the client agrees...
    Thats how I plan to approach it.

    If you dont dot your i's and cross your t's, the client will find loop holes - and abuse them.
    I have found this out the hard way on previous endeavors..
    it depends on how much time you have to dedicate to 1 application.
    i sold an application to my dad's friend + he was always calling me for advice + asking me round to fix his screwups.
    eventually i told him it was unacceptable even though he would pay me for every call out. i got into programming to be a programmer + not a program analyst...

Page 1 of 2 12 LastLast

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