Visual Basic
- Thread starter tmack
- Start date
This has been covered many many times.
Try a search on "Visual".
You'll get a lot of hits but it's in there somewhere.
Though some kind soul may do it for you.
And while you're waiting look up "MSCOMM" in VB6 Help. It'll also provide some very simple examples for the VB6/PC end of things.
That will provide you with background info when someone lists some code for you.
(Assuming it is VB6 as you haven't specified ????)
Try a search on "Visual".
You'll get a lot of hits but it's in there somewhere.
Though some kind soul may do it for you.
And while you're waiting look up "MSCOMM" in VB6 Help. It'll also provide some very simple examples for the VB6/PC end of things.
That will provide you with background info when someone lists some code for you.
(Assuming it is VB6 as you haven't specified ????)
Which Visual Basic are you using ? I personally prefer VB6 but VB 2005 Express is available for free download from Microsoft ( dig around and Forum Search here to avoid having to register to get it, download the CD Image, burn that then install ) and that's what I'd recommend.
Unfortunately I've not done much with VB 2005, but I do have a VB6 Terminal Emulator which does shows how to use MScomm32 and has full source code -
http://homepage.ntlworld.com/the.happy.hippy/picaxe/aiterm.zip?2007-10-07
Unfortunately I've not done much with VB 2005, but I do have a VB6 Terminal Emulator which does shows how to use MScomm32 and has full source code -
http://homepage.ntlworld.com/the.happy.hippy/picaxe/aiterm.zip?2007-10-07
picaxester
Senior Member
I did a fair bit of development with FreeBasic but found it was getting further away from QuickBasic, lacking the features of VB, and, frankly, turning into a bit of a mess of a design. Feature creep, some fundamental design flaws, major changes between versions meaning code reqrite and no focus for where it's trying to go regrettably caused me to walk away from it. That was a year or more ago and things may have changed since.
FreeBasic was very solidly designed and robust so it looked like it had promise. Unfortunately it was lacking in what I needed and how I wanted to work. For Windows programming I consider event driven programming to be essential and that was lacking or incomplete, especially on the serial interfacing front which is essential for interfacing with PICAXE's.
A Forum Search should reveal discussion on other alternative programming languages, RealBasic, Liberty Basic, Delphi and so on.
FreeBasic was very solidly designed and robust so it looked like it had promise. Unfortunately it was lacking in what I needed and how I wanted to work. For Windows programming I consider event driven programming to be essential and that was lacking or incomplete, especially on the serial interfacing front which is essential for interfacing with PICAXE's.
A Forum Search should reveal discussion on other alternative programming languages, RealBasic, Liberty Basic, Delphi and so on.
Try Liberty Basic for driving Picaxe using RS232
Follow this link http://www.libertybasic.com/ - software is free & is well supported with an excellent forum just like Picaxe
Follow this link http://www.libertybasic.com/ - software is free & is well supported with an excellent forum just like Picaxe
Another freebie that works well for RS232 interfacing to micros can be found at http://www.processing.org/.
Tom
Tom
jodicalhon
New Member
Or JustBasic: http://www.justbasic.com/
This is a simplified version of Liberty Basic - it's free, simple and very useful.
No doubt there are bucket-loads more to choose from!
This is a simplified version of Liberty Basic - it's free, simple and very useful.
No doubt there are bucket-loads more to choose from!
picaxester
Senior Member
Tom2000, do you have an RS232 example for "processing"?
It sure would be nice if there were serial port example programs for all the languages we can use as it would make assessing them much easier all round. A simple terminal emulator is the best; what comes in gets displayed, what gets typed gets sent out. Good serial port interfacing is essential for a PICAXE project.
Most example code I find is usually the blocking kind involving waiting until something is received and that doesn't fit very well with a real world application where one wants timeouts and the ability to click cancel buttons, or to be doing something else until some data is sent to the application.
Most programming languages allow this asynchrnous bi-directional data transfer to be achieved, but it can be a lot more complex in reality -
The most impressive and innovative thing about VB was that it hid all this away behind the scenes and left programmers to deal with just "Sub GotSerialByte(b$)", "Sub GotKeyboardChar(k$)" and any other events which can happen. Once one gets used to event driven programming it's hard to go back, and thus VB has always been my benchmark for a good programming language. It's also what made it so easy to use compared to other alternatives. That's why it's still the third most popular programming language (11% according to TIOBE PCI ) behind C ( 14%) and Java (21%).
RealBasic offers similar to VB, but I've had too many problems with it and it's quite expensive. Delphi Explorer shot itself in the foot by not including a serial port object.
On the other hand, whatever you like and want to use is perfect if that suits. I still write most of my 'quick and dirty' one-off programs in MS-DOS PowerBasic.
Most example code I find is usually the blocking kind involving waiting until something is received and that doesn't fit very well with a real world application where one wants timeouts and the ability to click cancel buttons, or to be doing something else until some data is sent to the application.
Most programming languages allow this asynchrnous bi-directional data transfer to be achieved, but it can be a lot more complex in reality -
Code:
Do
If SerialByteReceived Then
b$ = GetSerialByte : Call Display(b$)
End If
If keyboardCharTyped Then
k$ = GetKeyboardChar : Call SendByte(k$)
End If
LoopRealBasic offers similar to VB, but I've had too many problems with it and it's quite expensive. Delphi Explorer shot itself in the foot by not including a serial port object.
On the other hand, whatever you like and want to use is perfect if that suits. I still write most of my 'quick and dirty' one-off programs in MS-DOS PowerBasic.
picaxester
Senior Member
Cool, thanks 
hippy,
can you let me know the duff points about RealBasic please.
I have only tried the demo and found the examples very good and there are a number of aspects that are superior to VB.
The most difficult bit I found was the editor , after being so 'used to' VB.
But if you could highlight problem areas then it might save me a quid or two.
Ta.
can you let me know the duff points about RealBasic please.
I have only tried the demo and found the examples very good and there are a number of aspects that are superior to VB.
The most difficult bit I found was the editor , after being so 'used to' VB.
But if you could highlight problem areas then it might save me a quid or two.
Ta.
@ Dippy : It was a lot of niggles piled up really. Pop-Up Windows appearing behind the application which locked it up, text focus disappearing entirely, text colour changing so typed text became invisible, and for myself particularly that the Import VB utility would simply hang or crash on any substantial project. I recall the biggest problem was that RB did not keep source as text files but used a proprietory fromat; that made it impossible to edit or generate source outside their application. When the last demo version I tried refused to run after installation that was the last straw. The minimum stated requirement now is 1GB RAM ( 2GB recommended ), and I don't have that. YMMV and things may have improved since I last tried it.
For a commercial user it's different but comparing $200/$500 ( plus $100/$250 yearly payment needed on top to get updates) with an entirely free VB 2005 Express if I were to move from VB6 made Microsoft the most logical and sensible choice. That RB developers still complain of bugs and alledge more interest in adding new features than fixing bugs. It also mandates paying the update fees to get rid of bugs. You need a Professional version if you want to be able to cross-compile to other platforms.
I guess this shows that it's hard to get an umimpressed developer back to a product and bad impressions linger. I'd always recommend everyone checks for themselves and does some research on what's available. Different people can have very different views of a product.
For a commercial user it's different but comparing $200/$500 ( plus $100/$250 yearly payment needed on top to get updates) with an entirely free VB 2005 Express if I were to move from VB6 made Microsoft the most logical and sensible choice. That RB developers still complain of bugs and alledge more interest in adding new features than fixing bugs. It also mandates paying the update fees to get rid of bugs. You need a Professional version if you want to be able to cross-compile to other platforms.
I guess this shows that it's hard to get an umimpressed developer back to a product and bad impressions linger. I'd always recommend everyone checks for themselves and does some research on what's available. Different people can have very different views of a product.
A quick cut and paste, but this is what a serial port comms subroutine looks in vb.net (vb express) It sends out a "hello world" and then waits for a reply, and gives up if no reply in 1 second.
vb.net is free. I'm perservering with it for this reason, as it is a completely different language to vb6. I think MS are morphing vb, C++ and Java into the same language which is a painful process but will be worth it in the end. I have been able to paste some whole slabs of C into vb.net and have it work, so I can see where they are going.
Imports System.IO
Imports Strings = Microsoft.VisualBasic ' so can use things like left( and right( for strings
Public Class Form1
Public Declare Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Integer) ' for sleep statements
Dim WithEvents serialPort As New IO.Ports.SerialPort ' serial port declare
Private Sub Form1_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load ' need all this rubbish stuff - .net puts it in automatically when go form1events above/load
' startup code here
End Sub
Sub SerialTxRx()
Dim SendString As String
Dim ResponseString As String = ""
SendString = "Hello World"
If serialPort.IsOpen Then
serialPort.Close()' just in case it was already open
End If
Try
With serialPort
.PortName = "COM1" ' Most new computers default to com1 but any pre 1999 computer with a serial mouse will probably default to com2
.BaudRate = 2400 ' baud rate
.Parity = IO.Ports.Parity.None
.DataBits = 8
.StopBits = IO.Ports.StopBits.One
.ReadTimeout = 1000 ' milliseconds timeout
.Open()
.DiscardInBuffer() ' clear the input buffer
.Write(SendString) ' send out the data
Call Sleep(300) ' 100 milliseconds minimum to wait for data to come back and more if data stream is longer
ResponseString = serialPort.ReadExisting ' read back the response
.Close()
End With
If Len(ResponseString) <> 0 Then
' insert code here to process the response string
End If
Catch ex As Exception
MsgBox(ex.ToString)' error
End Try
End Sub
vb.net is free. I'm perservering with it for this reason, as it is a completely different language to vb6. I think MS are morphing vb, C++ and Java into the same language which is a painful process but will be worth it in the end. I have been able to paste some whole slabs of C into vb.net and have it work, so I can see where they are going.
Imports System.IO
Imports Strings = Microsoft.VisualBasic ' so can use things like left( and right( for strings
Public Class Form1
Public Declare Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Integer) ' for sleep statements
Dim WithEvents serialPort As New IO.Ports.SerialPort ' serial port declare
Private Sub Form1_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load ' need all this rubbish stuff - .net puts it in automatically when go form1events above/load
' startup code here
End Sub
Sub SerialTxRx()
Dim SendString As String
Dim ResponseString As String = ""
SendString = "Hello World"
If serialPort.IsOpen Then
serialPort.Close()' just in case it was already open
End If
Try
With serialPort
.PortName = "COM1" ' Most new computers default to com1 but any pre 1999 computer with a serial mouse will probably default to com2
.BaudRate = 2400 ' baud rate
.Parity = IO.Ports.Parity.None
.DataBits = 8
.StopBits = IO.Ports.StopBits.One
.ReadTimeout = 1000 ' milliseconds timeout
.Open()
.DiscardInBuffer() ' clear the input buffer
.Write(SendString) ' send out the data
Call Sleep(300) ' 100 milliseconds minimum to wait for data to come back and more if data stream is longer
ResponseString = serialPort.ReadExisting ' read back the response
.Close()
End With
If Len(ResponseString) <> 0 Then
' insert code here to process the response string
End If
Catch ex As Exception
MsgBox(ex.ToString)' error
End Try
End Sub
Last edited:
It's not without reason that it has been called VB.Not and Fred.Net
I decided to stick with VB6 until there's a compelling reason to change, and I suspect that could be a way off. I just don't see the gain as being worth the pain at present.
Yes, that's exactly Microsoft's goal, a single runtime and 'assembler code' environment so programs can be written in any Microsoft ( or other ) language of a programmers choice then easily combined with whatever else others prefer to use in different parts of the same application project. The real benefit to the entire computing community is that .Net should be multi-platform by design. With a ported runtime code should run on Windows, Linux and Mac.
It's a brilliant idea. A brilliant strategy. It's generally been brilliantly executed. It's ballsed-up Visual Basic entirely. The beauty of VB was that it hid the crud but now it's surfaced. Where VB knew what it was expected to do when an object was dropped on a form and its code written, now it has to be told, and that's an awful lot of typing, greater opportunity to go badly wrong and a steep learning curve. You now need to know things you shouldn't have to. What was great about VB is what's been taken away. The irony is that VB could have been adapted to generate the exact 'assembler code' required without the syntax having to change much, and the VB 2005 IDE is entirely inferior to that of VB6.
I started writing my Terminal Emulator example programs. FirstBasic, VB3 and VB6 all done and tested in 30 minutes. Six hours on and I'm still battling VB 2005, and most of the work was done while I blinked by the VB6 Project Import utility. It works fine if I tell VB to 'ignore illegal cross-thread calls', but trying to turn them into legal cross-thread calls has me stumped. Apparently I need to understand Delegates in handling the received data event :-(
Anyway, I'm sure I'll solve the problem and porting to C# should be fairly straightforward after that. It would still be nice to see more Terminal Emulator examples written in other languages people use. It shouldn't be more than a half-hour job for the advocates of those languages, so there's a chance to test the proof of the pudding
I'll put my reference examples up in a .Zip file once I get VB 2005.
VB 2005 delegation sorted. C# isn't as smooth going as I'd hoped. RealBasic wasn't too bad, and easier than C#, also let's me give Dippy an update on why I'm not using RealBasic any time soon ...
The IDE doesn't respect my Windows Colour Theme.
Edit Fields ( Text Boxes ) don't default to Windows Colour Themes.
Every Run of the program from within the IDE triggers one or other, or more, Firewall Alerts ( Kerio ) which have to be clicked on.
The Build Window gets corrupted at times. It and others won't always go away and hog the Task Bar.
Then the real killer for me - The incredible migraine inducing flicker, redraws and flashing when switching between elements of the IDE.
I was going to say that the 15 day demo period to evaluate was far too short, but perhaps not
Time to go and lie down and let the headache pass.
The IDE doesn't respect my Windows Colour Theme.
Edit Fields ( Text Boxes ) don't default to Windows Colour Themes.
Every Run of the program from within the IDE triggers one or other, or more, Firewall Alerts ( Kerio ) which have to be clicked on.
The Build Window gets corrupted at times. It and others won't always go away and hog the Task Bar.
Then the real killer for me - The incredible migraine inducing flicker, redraws and flashing when switching between elements of the IDE.
I was going to say that the 15 day demo period to evaluate was far too short, but perhaps not
Time to go and lie down and let the headache pass.
Last edited:
Haha!
That's what VB6 likes to do with anything that moves :|
I also get flashing when using the "native styles" (XP/Vista styles instead of Windows 95/98
).I learnt VB6 before finding all of its down-points (absolutely no other platforms other than Windows/no [alpha] PNG support/no 32bit alpha icons/etc), so now I'm stuck with VB6 and a lot of trouble trying to learn/get used to anything else
I can understand some flicker with things moving but not when simply switching from one text display to another, and there's certainly no need to redraw the screen three or four times with a different coloured background inbetween, that's just bad design and coding.
I do note a fair amount of flicker with VB6 forms when using XP Themes but that's not really VB's fault; that's down to the OS and middleware. VB6 is absolutely fine in Classic mode.
Apart from being Windows only I haven't really run into many problems with VB6, but then I don't do many things with graphics. The biggest problems have been in making code work under XP, but that's IMO Microsoft destabilising the platform it once ran on perfectly.
I do note a fair amount of flicker with VB6 forms when using XP Themes but that's not really VB's fault; that's down to the OS and middleware. VB6 is absolutely fine in Classic mode.
Apart from being Windows only I haven't really run into many problems with VB6, but then I don't do many things with graphics. The biggest problems have been in making code work under XP, but that's IMO Microsoft destabilising the platform it once ran on perfectly.
Why wouldn't it work under XP? (I've never had any problems)
hippy:" The IDE doesn't respect my Windows Colour Theme."
I guess that's a personal thing.
Edit Fields ( Text Boxes ) don't default to Windows Colour Themes.
If they don't I think the default ones are perfectly clear - but, again, that's a personal thing.
Every Run of the program from within the IDE triggers one or other, or more, Firewall Alerts ( Kerio ) which have to be clicked on.
I don't get any problems at all re Firewall. I have hardware and Norton IS. Flawless.
The Build Window gets corrupted at times. It and others won't always go away and hog the Task Bar.
I've just tried this about 30 times - no problems....
Then the real killer for me - The incredible migraine inducing flicker, redraws and flashing when switching between elements of the IDE."
- eh? Switching has been flawless and instant. Could it be your PC?
I've found the demos quite impressive so far. Graphics pees all over VB6. As does pdf file display/handling.
But, in fairness, I've only been fiddling for 30 minutes. Let me try harder.... as I'm finding it a bit confusing to drive after VB6.
Note: I'm running the RealBasic 2007 Release 4 standard demo (15 days) on XP+SP2.
I guess that's a personal thing.
Edit Fields ( Text Boxes ) don't default to Windows Colour Themes.
If they don't I think the default ones are perfectly clear - but, again, that's a personal thing.
Every Run of the program from within the IDE triggers one or other, or more, Firewall Alerts ( Kerio ) which have to be clicked on.
I don't get any problems at all re Firewall. I have hardware and Norton IS. Flawless.
The Build Window gets corrupted at times. It and others won't always go away and hog the Task Bar.
I've just tried this about 30 times - no problems....
Then the real killer for me - The incredible migraine inducing flicker, redraws and flashing when switching between elements of the IDE."
- eh? Switching has been flawless and instant. Could it be your PC?
I've found the demos quite impressive so far. Graphics pees all over VB6. As does pdf file display/handling.
But, in fairness, I've only been fiddling for 30 minutes. Let me try harder.... as I'm finding it a bit confusing to drive after VB6.
Note: I'm running the RealBasic 2007 Release 4 standard demo (15 days) on XP+SP2.
My Windows Colour Theme : The problem there is that in places it shows black-on-black so I'm forced to alter my Theme for everything else to use RB.
Run-Time Colour Schemes : It's courtesy at least to configure an Application as the user wants it. Without any automatic mechanism it means the code has to do that itself every time it runs.
In respect of Application presentation ( and web sites ) in the UK, there's some duty on developers to ensure accessibility under the Disability Discrimination Act. The easiest route to compliance is to colour everything as the user has already told the OS they'd like them.
Firewall Triggering : Because of the way RB debugs the App via TCP/IP, Kerio watches who is opening connections then checks the App is the same as last time to detect hi-jackings and Trojans. The .exe being run of course has a different size / checksum everytime it is compiled, so a "replaced .exe" blocker pops up, and permissions are reset when an App is replaced, so then a "permit TCP/IP connection" pops-up.
Build Window Corruption : Could be because I'm cross-compiling for Linux / Mac platforms as well.
Flicker : It probably is my PC, most likely its slow 32MB graphics card, plus colour scheme mis-match. Microsoft OE 6 suffers similar problems ( I thus use OE 5 ); the existing text box ( black background ) is hidden, a new 'default white background' text box is drawn, text is added and then the background gets set to black. Or something like that and there's a horrible flash of white in there.
2007r4 : Ditto, XP+SP2. 135 year demo. It shouldn't be that easy to take an expired demo licence code and just change a couple of digits.
Run-Time Colour Schemes : It's courtesy at least to configure an Application as the user wants it. Without any automatic mechanism it means the code has to do that itself every time it runs.
In respect of Application presentation ( and web sites ) in the UK, there's some duty on developers to ensure accessibility under the Disability Discrimination Act. The easiest route to compliance is to colour everything as the user has already told the OS they'd like them.
Firewall Triggering : Because of the way RB debugs the App via TCP/IP, Kerio watches who is opening connections then checks the App is the same as last time to detect hi-jackings and Trojans. The .exe being run of course has a different size / checksum everytime it is compiled, so a "replaced .exe" blocker pops up, and permissions are reset when an App is replaced, so then a "permit TCP/IP connection" pops-up.
Build Window Corruption : Could be because I'm cross-compiling for Linux / Mac platforms as well.
Flicker : It probably is my PC, most likely its slow 32MB graphics card, plus colour scheme mis-match. Microsoft OE 6 suffers similar problems ( I thus use OE 5 ); the existing text box ( black background ) is hidden, a new 'default white background' text box is drawn, text is added and then the background gets set to black. Or something like that and there's a horrible flash of white in there.
2007r4 : Ditto, XP+SP2. 135 year demo. It shouldn't be that easy to take an expired demo licence code and just change a couple of digits.
Getting VB6 to use XP Themes is what requires most UI changes, particularly to get Radio Buttons to work, but also to make Command Buttons right at times. Enabling Theme support works and so do most controls, but Radio Buttons are all drawn on a black rectangle background and some Command Buttons can develop peculiar borders. To get round that it's necessary to put both within PictureBox wrappers. With Radio Buttons usually inside frames that can be quite a lot of cut and paste and twiddling with alignments.
Once resolved, XP itself flickers any Frames on the Form as the mouse moves in and out.
One difference running under XP which bit me hard was that it's not possible to use a top level menu click to set checked sub-menu items ...
Code:
Private Sub mnuPort_Click()
mnuPortAutoOpen.Checked = boolAutoOpenPorts
End SubI've had hours of fun trying to disable the Application Close Button [X] programmatically under XP; it keeps re-enabling it when I click on other controls and when the mouse passes over the Application's Title Bar.
ShellExecute etc work but under XP the "hidden App" can appear in the Task Tray while it runs.
I've never used Vista so no idea what sort of issues that throws up.
Fair enough; I am aware of the radio box issues.
I would use VB 2005 if they didn't make it so hard to find information about things (I have justifications for my complaints too
).VB 6 just seems simply and fast to run and create with, so I mostly use that, but it is becoming too old and outdated to use
I've disabled the 'X' button fine before and it didn't enable as far as I know, so I'm not sure how you achieved it :S
I'm not sure what you mean about the task tray, but setting "ShowInTaskbar" to false stops it appearing in the task bar.
The real issue with VB 6 on Vista is the installation (if you can even get it to work); you have to edit things, use admin mode, compatibility emulation, etc, to get it to install correctly. "Desktop composition" (Aero) also has to be disabled when using Vista because it uses outdated graphics drawing (it would cause lag - in seconds - when you try to select/move/insert/etc).
I got it working fine on Vista in the end
Last edited: