|
Glen Conaway wrote:
Additional information: Public member 'Text' on type 'String' not found.
The objects in ListBox.Items() are strings, so just try ListBox.Items(1), instead of ListBox.Items(1).Text.
Hope This Helps
|
|
|
|
|
Works great.
Many thanks,
Glen Conaway
|
|
|
|
|
Sorry for the late reply, but yes, drop the .Text. That's what I get for writing this stuff when I'm in a hurry to get out of work! 
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
I am at the stage that I realized that alot of my exceptions are being handled poorly, and have now created a class that will handle the exceptions that are thrown at one point in the program rather than at the many that existed before. (based on the article on exception handling on this site)
BUT, now that I am going through I see alot of places that I am unsure whether it is a place that should be within a try/catch block or not.
Here is a simple example:
let's say that you are about to create an object that requires one or more params. If the params are not there you do not want the code to continue because obviously the later code requires the object. Now this seems to me at this point to enclose this within a try/catch block. Is that wrong, because this kind of thinking would result in ALOT of t/c blocks throughout the program, and I know that they can take their toll on your system.
I guess that it is things like this that I am want to make sure of because I don't want to have to make a bunch of changes a couple weeks down the road to changes that I need to make now.
Thanks for the help.
|
|
|
|
|
another question:
is there any harm in only catching the std exception if you are not going to deal with any other exceptions differently? That is the way that I am doing it now, but I want to make sure.
Thanks again
|
|
|
|
|
We use the thread exception handler to catch all "unanticipated" exceptions. Then in code elsewhere we only write exception handlers for expected errors that we specifically want to do something about (file not found, etc.). We also include a fair number of Try/Finally blocks to be sure we cleanup when an error occurs (close files, release handles, etc).
This scheme seems to work pretty well ... but I would certainly be open to other opinions and ideas 
A person with one watch knows what time it is; a person with two watches is never quite sure ...
[remove "NFS-" from email (No Freaking Spam)]
|
|
|
|
|
===we only write exception handlers for expected errors that we specifically want to do something about (file not found, etc.).
what is the benefit of handling exceptions of that sort at that point? Because right now all mine are being thrown to the global e catcher  Is there any disadvantages that I am missing out on that will come to haunt me later?
|
|
|
|
|
kowplunk wrote:
what is the benefit of handling exceptions of that sort at that point? Because right now all mine are being thrown to the global e catcher Is there any disadvantages that I am missing out on that will come to haunt me later?
Well, if the user attempts to open a file, it would be nice to catch the FileNotFoundException and the tell user to try again (or jump off a bridge ), or the SecurityException so we can tell the user he/she's got insufficient rights to open the file, or ...
It just depends on what the function does and what you want to do in the even of an exception. Production quality code is HEAVILY populated with exception handlers just because of the little things like trying to open a file that doesn't exist. You could encompass your app with one giant exception handler, but that would also mean that any error would effectively stop your app in its tracks and you would have to restart it.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Blaiser wrote:
We use the thread exception handler to catch all "unanticipated" exceptions
Does this mean that you have the whole program running within one big t/c block?
|
|
|
|
|
kowplunk wrote:
Does this mean that you have the whole program running within one big t/c block?
Not really, but it does have that effect. I think of it as a last stop safety net; any errors that occur on the thread which are not otherwised handled get caught here.
Back in VB6, any production app worth its salt would have an error handler in every event routine because if an error occurs here, the app just croaks after VB gives its default error message.
But in .NET you can set an exception handler for the thread, and only write handlers for the errors you can do something about. Like Dave said, if the file a user selects does not exist, or is the wrong format, or they don't have the privs, I'll catch these, provide a specific message, perhaps log the occurance and move on. But if some other kind of error occurs that I don't anticipate, like "Index out of bounds" or "Object is Nothing" (i.e. a defect) then the global handler will catch this, log it, inform the user and give control back to the UI.
Now, as I said, we employ a good number of Try/Finally blocks through-out to be sure we release resources properly (close files, etc.), whether an error occurs or not. But the global handler has worked pretty well for us.
One last point, I would not loose too much sleep over the performance impact of having t/c blocks in your code. IMHO, excepting certain constructs (like tight loops), the impact is generally negligible relative to human response time in using the GUI. $0.02
A person with one watch knows what time it is; a person with two watches is never quite sure ...
[remove "NFS-" from email (No Freaking Spam)]
|
|
|
|
|
thanks for the info guys, it has definately helped.
|
|
|
|
|
Yes, this seems to be the recommended way to deal with exceptions according to a recent article. Was it at CP?
Kevin
|
|
|
|
|
Hi,
Could someone tell me if it is possible to reference an operator, such as "=" or "<" with a variable?
For example:
Dim Var1 as Interger
Dim VarRefOperator as ?????
Var1 = 10
VarRefOperator = "="
If Var1 VarOperator 10 Then ' If Var1 = 10
Msgbox("do something")
End If
Thanks,
weshill
|
|
|
|
|
There is no way to do that in VB.NET or any other of the 14 languages I'm familiar with. Frankly, I can't even think of a reason why you would want to do that... So, I'll ask, why would you want to do that?
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
I know it seems silly. I was hoping to limit my coding.
This is what I am trying to do...
I have a combo box with (=, <, >, <>) operators in it and a piece of code that executes depending on the operator the user selects. Without the option to assign the operator a variable my coding become slightly longer with the use of a select statment that checks each possible option.
Thanks,
|
|
|
|
|
Unfortunately, that's what your going to have to do. Even if you were to make a class that did something like, internally, the class would have to check to see which operator was involved, then make the appropriate branch to do the comparison.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
|
We have a WinForms component in it's own assembly which is used in our .NET desktop app; the window is set by the app to be an MDI child in the app's MDI window.
The component can also be used by other .NET apps that set a ref to our library. Lastly, the component can also be used as a standalone window for apps do not wish an MDI child for its functions.
Is there any way to expose this .NET component so that a COM app (C++ or perhaps VB6) could use the component as an MDI child?
Thanks ... Blaiser
A person with one watch knows what time it is; a person with two watches is never quite sure ...
[remove "NFS-" from email (No Freaking Spam)]
|
|
|
|
|
Well, it's too much to go into in the Forums. I'll say that is should have been a desgin consideration before you even started to code this. Yeah, it's going to be that messy... ThNick Parker put together a great little article[^] that describes what needs to be done, complete with examples.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Hello VB Gurus!
I have got a very little problem here. I got "an invalid procedure call or argument" when I inserted this code on on the Form_Load procedure:
txtDescription.SetFocus
With this, I could not have the text object, txtDescription, focused on form start-up.
Please check.
Thanks,
dj41984
"All we need are ones like you"
|
|
|
|
|
I think you can't set focus in form load because the UI of the form is not completed its setup yet. If you want a certain control to have focus on display, try setting it's tab index to the lowest value among controls on the form that can receive focus.
A person with one watch knows what time it is; a person with two watches is never quite sure ...
[remove "NFS-" from email (No Freaking Spam)]
|
|
|
|
|
Blasier is right about the controls. You can't execute methods on the controls in the Form_Load event. You can either set the TabStop to 0 for that textbox or you could do the .SetFocus() method on Form_Activated. But, using the Activated event has it's drawbacks. If the user switches to another app, then back to yours, the Activated event will fire. Same thing if you .Show() or .ShowDialog() another form. The end result of this will be that the focus will alwyas return to the same control when the user goes back to your form.
The best method is to set the TabStop on that control to 0.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
I got this code:
<br />
dim frm1 as new frmLogin<br />
dim frm2 as new frmMain<br />
sub main<br />
application.enablevisualstyles()<br />
frm1.showdialog()<br />
<br />
application.run(frm2)<br />
end sub<br />
It seems that the first form does not get the xp visual styles and the second form does. Is this a bug or is this expected? Can I ask why? Is there a work around? I need the first form to come before the second form so that I can configure the second form appropriately.
|
|
|
|
|
That's because you have the Application.EnableVisualStyles() in the wrong place. It should go before the Application.Run() for your main form, not inside it. The proper place for it in the Main function of your code. Just use Edit/Search and you'll find it. Also, put an Application.DoEvents() between the .EnableVisualStyles and the .Run for your app:
Sub Main()
Application.EnableVisualStyles()
Application.DoEvents()
Application.Run(new Form1())
End Sub
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Hi,may i know is it possible to convert speech to text with vb.net?May i know where will have such source of code for reference?thanks!!!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
