|
first of all, good discussion you had with CG, I enjoyed it a whole bunch! 
Dave Kreskowiak wrote:
"I for one, don't EVER leave a return value to chance, in any language. I've always used the Return statement and I've always set a default value as one of my first statements in my methods/functions."
More often than not I take advantage of the fact that the VB compiler returns the default value of a function's return type in cases where one is not provided. Why you ask? Well, it's just handy on occasions, especially during the dreaded task of UI development, where my focus is just to program against an interface, forgetting about all the implementation behind that interface. I know all I have to do is just add that one line of code you say you always add, but I just don't even worry about that, rather I just define the interface I want to work against and implement it later. I'll admit I have experienced some debugging issues as a result of doing so; that's why I wish the compiler would treat the issue as a warning, but not an error. Also, another area where I heavily use this behavior is when creating "abstract base forms". I'm sure you know that the form designer requires that the base form have a parameterless public constructor; otherwise, it blows up. Well, then how do you create an abstract base form to be used with the form designer? Well, you can't, at least I haven't been able to. So what I do is just create a non abstract base form with a series of virtual methods that don't return anything rather raise an exception when called directly, the intent being that the derived form needs to override them so that any template methods work OK. Again, I know, I know, I should just add that one line of code you add, but what can I say, I just don't, and in this case, why should I? So really, I have to disagree with you and CG. CG says it's just straight out bad, you say it's OK but you make sure never to fall to it, I say it's OK always, but that compiler should give a warning.
Finally, I once asked CG the same question, that is, what's his problem with VB. At first I just couldn't understand, but then I tried to put myself in his position of having to go through the painful task of having to work on sh*tty VB code and then his feelings seemed quite clear, although his famous words "VB.NET is crap" always make the hairs on my arms stand up in fury  .
Thanks for the discussion
|
|
|
|
|
Dave Kreskowiak wrote:
Just because a language has some bad features doesn't mean you should get lazy and use them. In my view, there's no excuse for writing bad code because you didn't recognize a bad feature.
I agree. My point is that, in general, there are more people in VB land that are likely to use bad features, and C# is better *because* the bad features are not there. I've written good VB code, but I had to do it by building on VERY bads VB code, worse code than it would be possible to write in C#.
Dave Kreskowiak wrote:
It's those idiots who refuse to upgrade their skills that are cranking out crappy code.
And in a world where you inherit projects from other people, the availability of those 'idiot features' are where the problem lies.
Dave Kreskowiak wrote:
I for one, don't EVER leave a return value to chance, in any language.
I would also set a default return value in the first line of code. But it's just one more thing to keep in mind when you're trying to figure out why someone elses code just plain doesn't work. And it's stupid.
Dave Kreskowiak wrote:
In my humble opinion, code is code, good or bad. It doesn't matter what language it's written in. As a universal law, no matter how perfect, or bad, you think any language is, the universe will always generate an idiot, to use it the wrong way.
I agree, totally. However, it's my experience that the universe generates more VB idiots, that code I've had to build on in VB is invariably terrible, code I've had to build on in C# and C++ is usually pretty decent.
Christian
I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
|
|
|
|
|
Christian Graus wrote:
So I *did* tell you something you can't do in C# ? It's sad, b/c I trust a C# programmer to dispose an object more than a VB programmer. The using keyword makes for nice code. You don't have it. Question answered.
It is not something you can't do in VB.NET. You simply implement the IDisposable interface. So VB.NET does not have a convenience that C# has. Big Deal. In either case, the same functionality is available. In VB.NET you can implement the code to explicitly close for example database connections, same as in C#.
In C# you could easily overlook whether someone included the "using" key word. In VB.NET you could also overlook whether someone explicitly called Dispose. I see no difference.
If anything the VB approach is clearer, because you explicitly call Dispose at the actual time the object is going out of scope. In C# you have to declare "using" when the object is created. In C# "using" can also refer to an alias for a namespace.
But in VB.NET you only have one issue to look for: Did the code call Dispose when the object went out of scope?
How can you really say this is a "feature" in C#? It is an opportunity to write confusing, bad code. VB.NET does not suffer from this "feature". It is quite clear what the code is doing - explicitly calling Dispose when the object goes out of scope. It is much more logical, much less prone to being overlooked.
Christian Graus wrote:
Deprecated features that by and large are in VB because the VB6 crowd complained. Deprecated stuff that is in use today, I've seen he production code, on new VB.NET projects.
It is the responsibility of the production teams to create and adhere to coding standards. Oner of those standards should be the use of structure error handling in VB.NET, which is the main area where a lot of deprecated features are still supported.
The problem is not the presence of deprecated features. If the coding team does not have any coding standards, they will tend to produce sh*tty code, with or without deprecated features.
Christian Graus wrote:
If I pursue a conversation like this, it's because I'm interested to see if any VBer can explain issues like magic return values ( you dodged that one
No you just did not bother to read my post other than to try to find areas to criticize. I provided a detailed explanation of why in practice the "magic return value" is a non-issue. I will not repeat myself. You can re-read my original post.
Christian Graus wrote:
On a personal level, VB's verbosity makes it look like the coding equivelant of See Spot Run, but that's just me. ...when C# is better for all the reasons I stated.
Sorry, but most of your reasons have been your opinion that all VB coders produce bad code.
Christian Graus wrote:
So why do you use VB.NET instead of C# ? Was it just comfortable for you ? You said you use C++, don't you find the VB synax annoying ? Does it really feel like programming to you ?
In C++ I am programming objects, and the code should be clear.
In VB.NET I tend to be programming GUIs which have a lot of code and event handlers. I don't have a personal bias against the See Spot Run syntax. The See Spot Run syntax you seem to dislike is an advantage in my opinion. It means I can quickly scan through a form's code and see what is doing what, because those End If and End Sub statements that you consider to be the hallmark of first grader's coding are in fact much easier to read than a page full of braces.
C# at least provides a structured IDE for coding. But spend a little time trying debug someone else's JavaScript code and you will quickly come to despise the brace syntax.
Maybe I have a personal bias against C# because instead of pandering to a previous version, it panders to J programmers, which I generally despise. 
Robert
|
|
|
|
|
rwestgraham wrote:
If anything the VB approach is clearer, because you explicitly call Dispose at the actual time the object is going out of scope. In C# you have to declare "using" when the object is created. In C# "using" can also refer to an alias for a namespace.
You're wrong. In C#, I can impliment IDisposable and call it myself. The using keyword is a piece of syntactic sugar ( as so much of C# seems to be ), that just happens to lower the risk, because you essentially declare that an item will need disposing at the moment you create it.
rwestgraham wrote:
I provided a detailed explanation of why in practice the "magic return value" is a non-issue.
I went back and looked for it. I didn't see anything that wasn't crap. ANY bad feature is not a problem if the language is used competently. The stars have just aligned so that one language has more bad features than any other, and more incompetent users also. Do you ever have to work on other people VB code ? If so, you'll know what I mean.
rwestgraham wrote:
Sorry, but most of your reasons have been your opinion that all VB coders produce bad code.
Sorry, but you can't accuse me of not reading what you say, and then come out with this. MOST VB programmers DO produce bad code. I've seen it. Most is a long was from all.
rwestgraham wrote:
It means I can quickly scan through a form's code and see what is doing what, because those End If and End Sub statements that you consider to be the hallmark of first grader's coding are in fact much easier to read than a page full of braces.
I can't believe anyone who can read C++ would make such a claim. It's intolerably hard to read. I prefer this brace style
if (VB == crap)
{
useCSharp();
}
and with this style, the indenting and the lining up of braces makes it crystal clear what is going on.
rwestgraham wrote:
C# at least provides a structured IDE for coding. But spend a little time trying debug someone else's JavaScript code and you will quickly come to despise the brace syntax.
LOL - someone else's code is always the problem. That's my point, too
rwestgraham wrote:
Maybe I have a personal bias against C# because instead of pandering to a previous version, it panders to J programmers, which I generally despise.
Who does it pander to ? Do you mean JScript, or J++, or what ? I admit, it looks a hell of a lot like Java, which I for one can't figure out.
Christian
I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
|
|
|
|
|
Christian Graus wrote:
You're wrong. In C#, I can impliment IDisposable and call it myself. The using keyword is a piece of syntactic sugar ( as so much of C# seems to be ), that just happens to lower the risk, because you essentially declare that an item will need disposing at the moment you create it.
I can implement IDisposable In VB.NET and call it myself too. You've yet to justify your argument that this is a functionality that C# provides that is not available in VB.NET.
Christian Graus wrote:
I went back and looked for it. I didn't see anything that wasn't crap.
No surprise there. It was an item from your list, not something you've actually used and understand anything about.
As for the rest of your statements, those are your opinions and your preferences. I'd rather have to try to figure out someone else's bad VB code than someone else's bad C++ code anyday.
Christian Graus wrote:
I admit, it looks a hell of a lot like Java, which I for one can't figure out.
It's no mystery. All C# really is: A Java like langauge because Microsoft wants to attract Java programmers and encourage them to use C#.
C# is not some great advance in programming languages. C#, VB.NET - it's all NET. Same framework, same code that ultimately runs on the machine, just different coding syntax (and not that different. I can easily translate code from VB To C# and back the other way, because they are really essentially the same platform.)
C++ is a different animal. But realistically VB.NET and C# are for most practical purposes one platform. If I need power programming I cannot get from VB.NET I switch to C++, not C# because I already know that I cannot really do anything in C# that I cannot do in VB.NET.
Sorry if you like to believe differently, but there really is little difference between the two.
Robert
|
|
|
|
|
rwestgraham wrote:
I can implement IDisposable In VB.NET and call it myself too. You've yet to justify your argument that this is a functionality that C# provides that is not available in VB.NET.
That's because you're being obtuse. I've made my position clear. Seriously, do you really not get it ? VB programmers are by and large clueless when it comes to issues like memory management, and so a syntax that doesn't require them to remember to clean up after themselves is more useful to VB than it is to C#, but only C# has it.
rwestgraham wrote:
No surprise there. It was an item from your list, not something you've actually used and understand anything about.
Wrong. I've used VB.NET, and I've seen plenty of code that relies on magic return values.
rwestgraham wrote:
I'd rather have to try to figure out someone else's bad VB code than someone else's bad C++ code anyday.
Perhaps. How does that change the fact that in my real world experience, the VB code is far more likely to be terrible ? Here's a for instance. You're asked to quote on extending a website, but you can't see the source code first. You quote, based on the assumption that the project is well laid out. It arrives, it's in VB.NET, and it's a total disaster, there is obviously no grasp of even the most basic software engineering principles in the past of this project. Your workload doubles, because you're having to do things in multiple places, and you're trying to refactor as well to make the code a bit easier to work on. This has happened to me several times in VB.NET, never in C#.
rwestgraham wrote:
All C# really is: A Java like langauge because Microsoft wants to attract Java programmers and encourage them to use C#.
That's a bit of an over simpliciation, I think, but it has a grain of truth to it. They marketed it as an evolution of C++ more than anything though.
rwestgraham wrote:
C# is not some great advance in programming languages.
I never said it was. Without ASP.NET, I'd regard it as a solution looking for a problem.
rwestgraham wrote:
C#, VB.NET - it's all NET.
Yeah, and it's all 1's and 0's at the end of the day. Anything else is just frameworks to manage complexity and help humans get it right.
rwestgraham wrote:
If I need power programming I cannot get from VB.NET I switch to C++, not C# because I already know that I cannot really do anything in C# that I cannot do in VB.NET.
Sure - I do the same with C# and C++. It's the same end result, but by adopting a C# only policy, I get to work on better quality legacy code, when I work on legacy code at all.
rwestgraham wrote:
Sorry if you like to believe differently, but there really is little difference between the two.
You are deliberately choosing to ignore the differences that I keep pointing out. Yes, they both compile to IL. I've heard it said that C# is faster, but I choose to disregard that, if I need speed, I need C++. But VB.NET has more idiot programmers, and more ways for them to shoot themselves ( and later me, if I need to maintain their code ) in the foot.
Christian
I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
|
|
|
|
|
Well, poorly written legacy code is an opportunity to get work. The language it was written in is usually the least important consideration to me personally.
I have three questions about any project:
1) Is there legacy code involved?
2) Was it written offshore?
3) What language is it in?
There are much worse evils out there than VB itself.
Robert
|
|
|
|
|
There is a thread in this forum on creating autocomplete for a simple textbox on a form. However, I am attempting to use autocomplete in a ComboBoxColumn on a datagrid and cannot figure out which event to trap. I thought it was the KeyUp event but I noticed that VB.NET plugs in a NoKeyUpCombo code as part of the syntax for adding dynamic comboboxes in the datagrid. Has anyone ever attempted this functionality and do you have any code supporting your attempt? Do I need to disable the NoKeyUpCombo code to make it work? Here is a snippet of my code:
#Region " Constructor "
Public Sub New()
mcmSource = Nothing
mblnEditing = False
ColumnComboBox = New NoKeyUpCombo()
ColumnComboBox.DropDownStyle = ComboBoxStyle.DropDownList
AddHandler ColumnComboBox.Leave, AddressOf LeaveComboBox
AddHandler ColumnComboBox.SelectionChangeCommitted, AddressOf ComboStartEditing
End Sub
#End Region
Select Case i
Case 3 'Use a combobox for the Test Type.
Dim ComboTextCol As New DataGridComboBoxColumn
With ComboTextCol
.MappingName = "TestTypeID"
.HeaderText = "Test Type"
.Width = 100
.ColumnComboBox.DataSource = ds1frmDataEntry.Tables("PUATTestType").DefaultView
.ColumnComboBox.DisplayMember = "TestType"
.ColumnComboBox.ValueMember = "ID
.NullText = ""
tableStyle.PreferredRowHeight = .ColumnComboBox.Height
tableStyle.GridColumnStyles.Add(ComboTextCol)
End With
Case 5 'Use a combobox for the County.
Dim ComboTextCol As New DataGridComboBoxColumn
With ComboTextCol
.MappingName = "CountyID"
.HeaderText = "County"
.Width = 100
.ColumnComboBox.DataSource = ds1frmDataEntry.Tables("County").DefaultView
.ColumnComboBox.DisplayMember = "CountyName"
.ColumnComboBox.ValueMember = "CountyID"
.NullText = ""
tableStyle.PreferredRowHeight = .ColumnComboBox.Height
tableStyle.GridColumnStyles.Add(ComboTextCol)
End With
|
|
|
|
|
I have coded a combo box to auto complete based on a collection of names that I load. The combo box is working great in Windows XP, but when we run the same application in NT the events for the combo box don't seem to all work. Are there some events that do not work in NT but work on 2000 / XP? If so is there a compatibility list somewhere that we can refer to?
Any help or feedback is appreciated. 
Lost in the vast sea of .NET
<a href="http://www.komputing.com/Pricelist.html">Visit my website at www.komputing.com</a>
|
|
|
|
|
No, all event should be working without any problems. Is the NT machine running NT 4.0 Service Pack 6a? Is the .NET Framework installed on this box the same version as the one the app was developed on? Any .NET Framework Service Packs installed on one, but not the other?
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Yes, we've actually double checked the framework service packs and they are the same as the XP machine. The NT image is 4.0 SP6a with framework 1.1 and all the patches.
I've actually created a textbox where I write debug messages to and I can see how in XP the events fire in a different order than they do in NT. I've started an MSDN call to see if I can narrrow down why. 
Lost in the vast sea of .NET
<a href="http://www.komputing.com/Pricelist.html">Visit my website at www.komputing.com</a>
|
|
|
|
|
Wierd!
Good Luck! Let us know what MS comes up with!
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Microsoft has been working with us for a few days with the MSDN call. The information that has come out of their research is that service pack 6a along with framework 1.1 and the patch for 1.1 is not enough. The version of user32.dll (which contains the win32 ComboBox) is not up to date to function correctly. Microsoft’s security patch Q834852 (http://support.microsoft.com/default.aspx?scid=kb;en-us;834852 ) updates the user32.dll to correct the problem.
I'm not sure why a security patch fixes combobox functionality, but I guess the moral of the story is that ALL security patches need to be applied when testing a VB application.
What was wierd was that our application did not work on the NT system we created, but when we installed Office 2000 the VB application worked. Office 2000 updated the user32.dll. We worked with Microsoft to find a solution, other than installing Office, to make our VB app function correctly. The security patch is what they recommended.
Lost in the vast sea of .NET
<a href="http://www.komputing.com/Pricelist.html">Visit my website at www.komputing.com</a>
|
|
|
|
|
The controls are not specific to VB.NET. Most of the controls you find in the ToolBox are .NET managed code wrappers around the actual controls built into Windows. That's why the controls can look the same from application to application. If you used C# to write your app, the same thing would have happened.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Hi guys Im really really stuck with this and I need sum help
basically I want the track bar linked to the sound I dowloaded wen the sound is downloaded I can use the track bar to go a spefic point in the song how do I do this
Dim OpenFile As New OpenFileDialog()
' Configure the dialog
With OpenFile
.InitialDirectory = "G:\"
.Filter = "MP3 Files (*.mp3)/*.mp3/
.CheckFileExists = True
' Open the dialog
If .ShowDialog = DialogResult.OK Then
PlayMCI(.FileName)
End If
End With
End Sub
|
|
|
|
|
Not enough information. How are you playing the file? Are you using the Multimedia MCI control? P/Invoking functions directly? Which ones? ...
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Hi AndyYie This is how I have decalred MCI sound
End Function
Public Function PlayMCI(ByVal filename As String, Optional ByVal ShowMsg As Boolean = False) As Boolean
If SoundFormat(filename) <> "NotSoundFile" Then
' close any previous commands that have opened the media
mciSendString("Close all", 0, 0, 0)
' and create the string which will open the new one
mciSendString("Open " & Chr(34) & filename & Chr(34) & " Type " & SoundFormat(filename) & _
" Alias Med", 0, 0, 0)
' Playthe(File)
mciSendString("Play Med", 0, 0, 0)
mciSendString("MCI_RECORD", 0, 0, 0)
End If
End Function ' Play MCI
Private Function SoundFormat(ByVal FullPath As String) As String
Dim Sound As New FileInfo(FullPath)
Dim FileExt As String = Sound.Extension.ToLower
Select Case FileExt
Case ".wav"
Return "Waveaudio"
Case ".mid"
Return "Sequencer"
Case ".mp3"
Return "MPEGVideo"
Case ".mpg"
Return "CDAudio"
Case ".wma"
Return "MPEGVideo"
Case ".mpeg"
Return "Windows Media Player"
Case Else
Return "NotSoundFile"
End Select
End Function ' SoundFormat
Hope this helps you to understand what Im doing
|
|
|
|
|
I've never gone through the MCI API functions, but it looks like you can probably get away with using the MCI Command STATUS WAVEAUDIO LENGTH to get the length of the media file. Use that as the maximum value for the TrackBar. You'll probably have to do some translating to get the time returned by STATUS into a more usable format, like converting the total time to total seconds.
In order to get the current position of the playback, you'll need to setup a timer and poll for the position status using the STATUS WAVEAUDIO POSITION command. This too will be returns in a time format. Convert it to seconds as before and you can use that to update the position of the TrackBar.
Same thing with seeking with the TrackBar. Convert the number of seconds returned by the position of the TrackBar into the appropriate time format, then use the SEEK WAVEAUDIO TO POSITION command to control where in the file to resume playing.
Sorry, I don't have any example code, 'cause liek I said, never played with it before.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Thanks Dave
Dnt wanna be a pain but I was wondering if you can give me a vb.net example of what you mean tat way I can understand it better
|
|
|
|
|
Hi David
What Ive managed to is. Thiis at the moment does nothing but when I fiddle with the trackBar a little noice disturbance is caused....
TrackBar1.Maximum = 100
TrackBar1.Minimum = 0
TrackBar1.TickFrequency = (mciSendString("Play Med", 0, 0, 0))
|
|
|
|
|
Well, I don't have any. I can't wip anything up in the near future either, because I don't have Visual Studio .NET here at work (not allowed to install it anywhere!), and I won't be home until the wee hours of Friday morning.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Hi Dave
Ive been looking at sum vb code this is what i got. No if Im not mistaken the below method allows u to play anyt part of the wav file? if im not mistaken. if the code is correct then what parts would I need to change soo that I can use it in my trackBar.
Any position within a WAV can be set by using the seek command. This also sets the position of the WAV for PLAY. The example below sets the WAV starting position to 1000 (milliseconds).
i = mciSendString("seek voice1 to 1000", 0&, 0, 0)
|
|
|
|
|
Like I said, I've never played with MCI stuff, so I can't tell you if this is going to work or not. It's trial and error...
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Please some can tell me how to start a process when the windows starts.Well some one told me that we can do it by making some changes in win.ini files but there is no such thing in win.ini file. So can anyone help me in this problem.
|
|
|
|
|
If you want a application to start on Windows startup, then write your application as a Service. If you want it to start when a user logs in, then a normall application can be written and launched from the Registry's Run key at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
