X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
2 Pages V < 1 2  (Go to first unread post)
   Reply to this topicStart new topic
> Questions On Visual Basic 6    
post Yesterday, 02:46 PM

UtterAccess Editor
Posts: 17,589
Joined: 29-March 05
From: Wisconsin

PC User,

> Maybe you guys forgot that in my original post that I introduced my self as an amateur programmer and I've used VBA in MS Access for my projects before I retired

Not really. Why do you say that? Just to clarify what I understood from that post: You have some experience with VBA and you want to know if that will make learning/developing in VB6 easier. This is backed up by this quote from you:
I'm looking for a simple transition to use the VBA code from Excel and/or Access into a stand alone application that I might create using Visual Basic 6 or whatever else might work.

You seem to be having trouble expressing what you want, which is causing some confusion now.

In your other discussion from this year, your subject line and a bold-highlighted bit in your post to ask "how to create an Access database table using Visual Studio 2017", not how to create a database in Access. Those are two very different things. I took it to mean that you do NOT want to work with Excel or Access, and that your primary focus was to create a "stand alone application". I didn't see anything that answered my question for WHY you wanted to do this, and as far as I can tell, you are now saying that I should have figured it out for myself, rather than answering my question directly. I wouldn't exactly call that "hostile" but it's leaning towards condescending.

> As for creating a database in my other post, I can do that in MS Access and create a link to the tables in my VB6 Development Software.

Keep in mind that VB6 was discontinued before the .ACCDB format was released. The sort of link you're describing will not be easy, which takes me back to the question you won't answer: why are you making this so difficult for yourself? If you're going to create a database in MS Access as you just described, why would you need VB6 at all? Just use the VBA platform available inside the database you are planning to create.

Frankly, at this point I feel like you're trying to tell me you don't want my help because you don't like the information I'm providing for you. If I'm wrong, please let me know. Otherwise, I can just back out of this conversation at this point.

Hope this helps,


(;,;) Li'l Cthulu says: Please talk about what you're trying to do, as well as how you're doing it.
Changing your real table name to "Table1" and your real form name to "Form1" in your posts makes it more difficult to understand what's going on, not easier.
Guidelines for Posting Questions
Go to the top of the page
post Today, 08:17 AM

UA Admin
Posts: 30,445
Joined: 20-June 02
From: Newcastle, WA

That's not quite true, is it?

If the question is specifically about some aspect of using VB6, then the appropriate answer would be related to VB6.

In this case, the question is rather more general and has to do with what coding languages are viable. And suggesting that a more modern coding language is more appropriate does make sense

Go to the top of the page
post Today, 08:21 AM

UA Admin
Posts: 30,445
Joined: 20-June 02
From: Newcastle, WA

Let's return, if we can, to the basic issue.

That is, if I understand correctly, the original question was whether you can ask VB6 questions here.

Of course, you can. VB6 is pretty much obsolete, and very few working developers are still trying to use it much, I suspect. However, I am pretty sure there is a fairly significant number of legacy VB6 applications out there running just fine after 15 or 20 years. If you are being called on to support one of those legacy applications, learning about VB6 would be useful. Trying to create a NEW application with VB6, probably not so much. I have a friend who has converted at least two such applications over to Access precisely because the original developers of the VB6 applications were no longer around to help--one such developer quite literally had died leaving his application an orphan with no source code and no documentation.

Please try to understand, asking about VB6 is a lot like asking if you can use Latin when you visit Rome, instead of modern day Italian. The answer is neither "yes" nor "no", but rather, "It depends." Italian does derive from Latin, but expecting Romans to be comfortable with Latin might be asking a bit too much. You might run into a few people who still know enough Latin to talk to you, but you just can't count on it for day to day activities.

With regard to the assertion that "...the code used in MS Access and MS Excel are easily used in Visual Basic 6...", I'd also say that that is probably a bit of an overstatement, albeit with a grain of truth at its core. VBA shares a common root with VB6, but they aren't really the same thing at all (Latin and Italian, right?).

Rather than trying to mix and match inappropriately, therefore, I'd say the more useful move would be to try to get up to speed with one of the more modern languages.

For Microsoft Office applications like Access and Excel, the appropriate coding language is VBA. For a stand alone application you'd probably want to pick something more appropriate than VB6, like VB.Net, for example.

Finally, you might consider it "hostile" to suggest that there's a better way. I don't. I consider it practical advice.

If you want to use Access or Excel, concentrate on VBA. If you want to create a stand-alone application which you can compile into an executable, then concentrate on something else, like VB6 or VB.Net.

It sounds like you intend to stick with VB6, and that is just fine. Understanding the limitations of that choice will help.

Go to the top of the page
post Today, 12:59 PM

UtterAccess VIP
Posts: 2,509
Joined: 12-April 07
From: Edmonton, Alberta Canada

To be fair, having used VBA (access + office code), and that of VB6? Well, they are “very” similar if not identical in coding syntax. So the syntax is near identical – the form objects and report objects are very different in Access. Since “most” code tends to interact and work with forms then the approach to “how” you code as opposed to the actual syntax is the challenge.

Keep in mind there is a “free” runtime for Access. So you can create applications in Access, and deploy the runtime + your application to machines without Access. And to be fair, the SAME really was the case with VB6. While it produces an .exe file, you STILL have to ensure that the VB6 runtimes are installed (thankfully, the VB6 runtimes are installed by default with windows – but you STILL using a runtime).

Last but not least:

You can download and use the free edition of Visual Studio and vb.net. I would “ignore” the comments that using vb.net is some “huge” deal or some “huge” learning curve. You can adopt vb.net, and code just like VB6, or just like Access. You do NOT have to adopt “OO” or so called object orientated programming to use vb.net. In fact the creating of class objects in vb.net, VBA and VB6 is virtually identical anyway.

So what I saying is that if I had to “now” adopt some system that allows me to create a stand-alone .exe file, then vb.net would be a fantastic choice if I had VBA or VB6 skill. In other words, the syntax and “general” coding of vb.net again is really identical to VBA (but again, the main difference being that form objects are very different in VB6 or vb.net).

What is really nice about Visual Studio, is you can also create web application and AGAIN get to code in a “familiar” VB language.

For example let’s build an Access form with a text box, and a button. When we click on the button, we want the text box to be filled with the numbers 1 to 10.

The Access VBA code would look like this:

   Dim i        As Integer
   Dim str      As String
   For i = 1 To 10
      str = str & i & vbCrLf
   Next i
   Me.Text1 = str

The form would look like this:

Now, let’s do the same thing, but use vb.net. And for fun, lets create a WEB application.

Now create a web form. Drag + drop a button on the web form, drag + drop a text box (so we drag controls from the toolbox – just like in Access or VB6).

And the code behind the button? Well, lets just cut + paste from Access!

We get this:
        Dim i As Integer
        Dim str As String

        For i = 1 To 10
            str = str & i & vbCrLf
        Next i

        Me.Text1.Text = str

Note that the ONLY change was the very last line. And to be fair??? If this was VB6, then ZERO changes in the desktop example and the web example would exist.

So in VB6, to set the value of a text box, we use “.text”. This was always a minor difference in VB6 vs VBA.

Ok, so we drag + drop a button and text box into our web form. The thinking, the syntax, the ideas – the whole approach in this example is really the same as what you would do with VB6, or VBA.

The resulting web form thus displays this:

So for building web applications, or desktop, I would STRONG recommend you use Visual Studio and vb.net. The reason for this is that coding of forms etc. in vb.net and VB6 are for the most part identical. Near zero learning curve between the two systems.

In other words, if you built forms and used VB6, then you coding and dealing with un-bound forms, and even the coding syntax for vb.net will be indistinguishable from VB6.

There is IMHO zero learning curve to use vb.net if you coded in the past with VB6. The advantage however is Visual Studio allows you to create not only desktop applications with VBA like code, but also create web based applications with a VBA like coding language.

The learning curve of jumping from VB6 to vb.net is LESS than that of jumping from Access/VBA to VB6.

If you coded in the past using VB6, then using vb.net will have LESS learning curve then jumping from VB6 to Access.

And the Visual Studio express studio is really a killer development platform, better then VB6, and it is free and based on the LATEST technology bits and parts from the folks in Redmond.

Albert D. Kallal (Access MVP, 2003-2017)
Edmonton, Alberta Canada
Go to the top of the page
post Today, 02:55 PM

Posts: 362
Joined: 26-May 15
From: The middle of Germany

I have a spreadsheet to download End Of Day (EOD) data from the Yahoo Finance API and a spreadsheet to download the Intraday End Of Day (IEOD) data from the Google Finance API and I don't experience any stress or strain in using them. Someone here said that the code in MS Excel is VBA, which is similar to VB6, not VB.NET yet the VBA code in the spreadsheets seem to easily download the data.

I know nothing about the implementation of your Excel solution. So, I can't say if it will be easier to port your particular solution to VB6 or VB.net.
If your solution is mostly compatible to Excel 97 or Excel 2000 then it will probably be fairly easy to port it to VB6.
If your solution uses some of the web connectivity in newer versions of Excel, you still can port the VBA code to VB6. However, you might be in for a nasty surprise when parts of Excel that your code relied on are just not there. In the latter case it might be actually easier to port the code to VB.net.

In any case, keep in mind that there is nothing similar to the versatile spreadsheet UI you get for free in Excel in either VB6 or VB.net.

The shocking revelation about digital signatures for accdb files.
Go to the top of the page
2 Pages V < 1 2

Custom Search
RSSSearch   Top   Lo-Fi    19th September 2017 - 05:30 PM