|
Dim index As Integer
index = listbox1.SelectedIndex
listbox1.Items.RemoveAt(index)
The above code is used to remove the seleceted item from a listbox. However the program crashes when the button is clicked and no item is selected. How can I correct??
|
|
|
|
|
Check the value of SelectedIndex before you use it. SelectedItem will be -1 if there is nothing selected.
You might also want to check to see if the number of Items in the Items collection (see it's Count property?) is greater than zero before you try to remove something from it.
|
|
|
|
|
You asked this question yesterday and I answered it[^].
Which part of my advice did you not understand?
Paul Marfleet
"No, his mind is not for rent
To any God or government"
Tom Sawyer - Rush
|
|
|
|
|
Maybe he wants to be sure, but very sure, so he asks to the whole village!
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
As the other posters above have stated, SelectedIndex will return -1 if there is nothing selected, so all you have to do is write an IF statement around it.
Dim index As Integer<br />
<br />
index = listbox1.SelectedIndex<br />
If index > -1 Then listbox1.Items.RemoveAt(index)
|
|
|
|
|
Can you help me solve this problem?
I’m using VB.NET 2005 and I’m trying to create a Server Application which can be early bound to by two Client Applications and exchange data between them via the Server Application.
Scenario: There are three applications ClientApp1.exe, ClientApp2.exe & ServerApp.dll all residing on the same server/workstation.
The 2 ClientApps are both manually started and both early bind to the ServerApp.
ClientApp1 sends a message to ClientApp2 via the ServerApp.
ClientApp2 replies to ClientApp1 via the ServerApp.
Do you know how I can create a ServerApp in VB.NET to achieve this?
Every time I create a ServerApp.dll (with a singleton class) and run the two ClientApps they both see different instances of the class.
I think the ClientApps are creating multiple instances of the ServerApp.dll. How do I stop this from happening?
ServerApp.dll
Public Class clsServerApp<br />
Private mstrStartup As String<br />
Private Shared myInstance As clsServerApp<br />
Public Shared ReadOnly Property GetInstance() As clsServerApp<br />
Get<br />
If myInstance Is Nothing Then<br />
myInstance = New clsServerApp<br />
End If<br />
Return myInstance<br />
End Get<br />
End Property<br />
Private Sub New()<br />
mstrStartup = "clsServerApp [Creation Time: " & DateTime.Now.ToString() & "]"<br />
End Sub<br />
Public ReadOnly Property Startup() As String<br />
Get<br />
Return mstrStartup<br />
End Get<br />
End Property<br />
End Class
ClientApp1.exe & ClientApp1.exe
Public Class frmClientApp<br />
Private objServerApp As ServerApp.clsServerApp<br />
Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load<br />
TextBox1.Text = objServerApp.GetInstance.Startup<br />
End Sub<br />
End Class
Both ClientApp1.exe & ClientApp1.exe early bind to ServerApp.dll but when run both receive different times proving that the singleton class is produces twice...
Regards
Andy
|
|
|
|
|
What does the code look like that's hosting your server object? Are you using a configuration file or creating it in code?? What does that look like??
|
|
|
|
|
Sorry Dave I don't really understand your question as I'm new at this?
I created a new project called ServerApp using a ClassLibrary as a template in VB.NET 2005. Then created a singleton class as in my code snippet in my original mail. Then selected Build ServerApp which created a ServerApp.dll
I then created two test ClientApps (as in my first mail) to read the time the ServerApp was created expecting the same time in both my ClentApps but I was wrong. The ClientApps were early bound to the ServerApp.
Both ClientApps returned different ServerApp creation times suggesting that they were creating their own instance of the ServerApp.
I'm trying to create a ServerApp that can exchange data between bound ClientApps.
Regards
Andy
|
|
|
|
|
Andy Dale wrote: Then selected Build ServerApp which created a ServerApp.dll
The .dll doesn't do you any good if it's not hosted in a 3rd application. The .DLL is being used directly by your client apps. Each is getting it own copy of the .DLL, and hence it's own singleton version of it.
Have you looked into .NET Remoting at all?? Or, if using .NET 3.0, WCF??
|
|
|
|
|
two.My.Settings.turveset = "false"
I want to write data back to my config file with the statement above but get an error message saying "property turveset is readonly". searched help for it but couldnt find how to make it readwrite or something.
help response for error message:
You have tried to assign a value to a property that is declared ReadOnly.
Error ID: BC30526
To correct this error
Remove the ReadOnly specifier from the property declaration.
 How to i do that?
|
|
|
|
|
jaska94 wrote: two.My.Settings.turveset = "false"
I want to write data back to my config file with the statement above
You can't do that. The setting you specified is an Application settings and is permanently read-only. You could change the desginer generated code, but any changes you make will be lost.
User settings are Read/Writeable. Application settings are ReadOnly.
If you wanted to change an Application setting, you would proabably have to use the ConfigurationManager class in the System.Configuration namespace, or use the standard XML document classes to manipulate the file. In either case, the setting in the running application will not change until the app is restarted.
|
|
|
|
|
thanks you solved the problem i didnt know that user settings are read/writable so i was looking at wrong direction 
|
|
|
|
|
What's the best way to capture all keyboard input for a RichTextBox control? I'm writing a terminal-style application, and so all keyboard input should be sent to the remote device without appearing in the RichTextBox (echoed data, if any, be displayed when it arrives). Putting in a KeyPress handler works, but if the control is not locked people can mess it up by pasting data into it; if it is locked, every keypress results in a "ding" before each KeyPress event. Is there any way to have the control locked but eliminate the "ding"?
|
|
|
|
|
in the keypress event take the key and send it then execute the line e.handled=true
|
|
|
|
|
I do that. If the RichTextBox is ReadOnly, the "ding" happens before they KeyPress event fires. If it's not ReadOnly, then something like shift-Insert will put text in the control without the event firing at all.
It would probably be possible to use the KeyDown event to watch for shift-Insert, but that could fail if the particular system is localized or configured to allow other methods of copy/paste.
|
|
|
|
|
you could try and turn keypreview on for the form - so it gets the keystroke first and in the form's keypress event test if the active control is your textbox and if it is, then send the key and e.handled=true
|
|
|
|
|
you could try and turn keypreview on for the form - so it gets the keystroke first and in the form's keypress event test if the active control is your textbox and if it is, then send the key and e.handled=true
That works except for the 'enter' key, which still generates the 'ding' if the textbox is readonly, and inserts a newline before the form's keypress event fires if it isn't.
Adding code to the 'keydown' event to toss set e.handled=true if e.keydata=keys.enter seems to have eliminated the 'ding'. Thanks.
|
|
|
|
|
hello
In VB how can we "locate a wireless lan node in adhoc network using RSSI and
triangular theorem approach "
kindly tell me
|
|
|
|
|
Why does this sound like you copied and pasted it either out of a homework assignment or out of the requirements for an application you were hired to write??
The question, as stated, has nothing to do with VB and suggests that you have no idea what you're asking about.
RSSI is simply the perceived strength of a signal received by the wireless card. I'm guessing that you're trying to triangulate the physical location of a wireless transmitter.
Well, using only a single wireless laptop and watching the signal strength it can't done. Since it's impossible to get any direction information from the wireless card, you'd have to build a database of signal strengths from varying points in the world as you walk around with your wireless laptop. The data would then have to be interpreted to build a map of the area and provide POSSIBLE points of origin of the suspect signal, but based solely on signal strength.
Using more laptops would not help with anything other than generating the map faster since none of the wireleess cards in the laptops can provide you with any data telling you which direction the signal is comming from.
Also, to complicate matters, the signal strength will vary as you walk around since the signal tends to go through some objects, like walls, floors, and ceilings, and completely bounce off others, like walls, floors, and ceilings. The signal strength will vary depending on the materials the signal is passing through/bouncing off of.
|
|
|
|
|
try this site it might help http://www.beesync.com
Public Class Form1
Private Sub axPacketXCtrl1_OnPacket(ByVal eventSender As System.Object, ByVal e As AxPacketXLib._IPktXPacketXCtrlEvents_OnPacketEvent) Handles oPktX.OnPacket
Dim I As Short
Dim thisPacket As String
Dim SourceIP As String
Dim DestIp As String
Dim item As New ListViewItem
thisPacket = ""
For I = 0 To e.pPacket.DataSize - 4
thisPacket = thisPacket & Chr(e.pPacket.Data(I))
Next
If e.pPacket.Data(14) = 69 And e.pPacket.Data(23) = 6 Then
SourceIP = e.pPacket.Data(26) & "." & _
e.pPacket.Data(27) & "." & + _
e.pPacket.Data(28) & "." & + _
e.pPacket.Data(29)
DestIp = e.pPacket.Data(30) & "." & _
e.pPacket.Data(31) & "." & + _
e.pPacket.Data(32) & "." & + _
e.pPacket.Data(33)
item.SubItems(0).Text = SourceIP
item.SubItems.Add(DestIp)
item.SubItems.Add(e.pPacket.DataSize)
lvPackets.Items.Add(item)
End If
End Sub
Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
Me.Button1.Enabled = True
Me.Button2.Enabled = False
With lvPackets
.Columns.Add("From", 130, HorizontalAlignment.Left)
.Columns.Add("To", 130, HorizontalAlignment.Left)
.Columns.Add("Size", 130, HorizontalAlignment.Left)
.View = View.Details
End With
Dim i As Integer
For i = 1 To oPktX.Adapters.Count
If oPktX.Adapters(i).IsGood Then
Me.ComboBox1.Items.Add("(" & i & ") " & RTrim(LTrim(oPktX.Adapters(i).Description)))
End If
Next
End Sub
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
On Error Resume Next
Me.oPktX.Start()
Me.Button1.Enabled = False
Me.Button2.Enabled = True
End Sub
Private Sub Button2_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button2.Click
On Error Resume Next
Me.oPktX.Stop()
Me.Button2.Enabled = False
Me.Button1.Enabled = True
End Sub
Private Sub ComboBox11(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles ComboBox1.SelectedIndexChanged
Select Case Me.ComboBox1.SelectedIndex
Case 0
oPktX.Adapter = oPktX.Adapters(1)
Case 1
oPktX.Adapter = oPktX.Adapters(2)
Case 2
oPktX.Adapter = oPktX.Adapters(3)
Case 3
oPktX.Adapter = oPktX.Adapters(4)
Case 4
oPktX.Adapter = oPktX.Adapters(5)
End Select
MsgBox(oPktX.Adapter.Description)
End Sub
End Class
|
|
|
|
|
I've just read Mr. Turini's article about exception-handling practices http://www.codeproject.com/dotnet/exceptionbestpractices.asp and I'm not quite clear on some things. I'm used to writing in C, with functions that return success/failure codes. While one must strive to avoid the temptation to simply ignore return codes, the use of success/failure codes allows code to progress sensibly when things don't work.
Suppose I'm reading in a bunch of dates (text format) from a file and I wish to convert them into a datetime format, using some default value if things don't work. Is there any practical alternative to writing a wrapper function to convert string->date, using a catch within the function to snag the dates that don't convert? If a generic "catch" is considered sloppy, is there a practical alternative to looking up every single function or conversion that might be expected to throw exceptions to find out exactly what exceptions it might return and risk having the application die if I miss one?
It seems to me that there are many situations, especially when accepting data from other sources, where failures are to be expected. My personal preference in such situations would be to use something akin to the IEEE floating-point NaN concept; if there's an arithmetic failure during an expression (division by zero, log of a negative number, etc.) return a sentinel value that will propagate through future expressions. Although a developer may sometimes wish for more detailed reporting of exactly why a complicated expression returns a NaN, most of the time the only thing that really matters is whether the expression evaluates or not.
Also, is there any good way in VB6 (since I'm still doing maintenance with that) or vb.net to make a program resume to the 'outer loop' when an error occurs, rather than dying altogether. If I have a button whose code is (VB6 style):
sub button1_click()
do_some_stuff()
a=sqr(-1)
do_more_stuff()
end sub
it would seem perfectly logical that the error in sqr() would prevent the program from running do_more_stuff(), but I see no particular reason the program shouldn't be able to try return to a state as though the button had not been pushed. To be sure, the program might not always work correctly after that point, but allowing the option to try would seem nicer than simply having it die totally.
|
|
|
|
|
Youre question is so broad that it's impossible to answer with anything shorter than an entire article. There's a bunch of different ways you can do this, all of which depend on your business rules.
You can start the loop and just process what you can up to the first error.
You can ignore errors for any lines and just keep going.
You can have the loop ignore errors and build a collection of processed objects, returning the completed collection.
Or you can create a collection that has both good data objects that passed processing AND exception objects for each one that failed.
Or you can create a loop that validates the data on each line without actually processing them and build a collection of exception objects for the lines that fail, ...
Or, ..., or, ..., or, ...
It depends entirely on your business rules and what you want/need to do with the good and bad lines in the data.
|
|
|
|
|
| It depends entirely on your business rules and what you want/need to do with the good and bad lines in the data.
Hmm... I just did a different query in the help file and found that the dateTime has a 'tryparse' method which does almost what I'm after, though the section of the help file on converting strings to other types didn't mention it for some reason.
I guess my more general question is what one is supposed to do if generic exception handlers are bad, if one doesn't really care about the specifics of any of the normal failure cases, and if there's no convenient way to determine in advance if an operation will work. If I allow the user to type in a number which should be in the range -1E250 to +1E250 and wish to validate it, must I look up the cdbl() function to determine what exceptions can be 'normally' thrown and then explicitly handle all of those? I would think it easier to make a little wrapper function:
function safedbl(st as string, defaultVal as double) as double
safedbl=defaultVal
try
safedbl=cdbl(st)
catch ' Who cares what went wrong?
end try
end function
but I understand generic catch instructions are frowned upon in such contexts. How else, though, can I validate the input to ensure that it will work?
If I didn't have to accept anything other than positive decimal integers, I could check to ensure the string contained only digits and wasn't obscenely long. I suppose the 'like' operator could probably used to individually check for all valid numeric formats, but that seems rather a waste. What's the 'right' approach?
|
|
|
|
|
Yes, catch-all Try/Catch blocks are frowned upon. Generally, people who use them just eat the error and don't report it, then wonder why their code doesn't work.
Yes, you should be looking up methods and function to see what exceptions they can throw. Then you can write your code to handle those specific cases. Generally, just trapping the root Exception class is a bit expensive because the Try/Catch block first sees if there is a handler for the specific exception. If there isn't one, then it looks to see if there is a handler for the parent class of the exception, and so on up the inheritence chain until it reaches the base Exception class.
I really don't recommend using the CDbl function anymore when Double.Parse and Double.TryParse are available. You get a bit more robust capability with the .NET conversion and type classes. For instance, Double.Parse will throw one of three exceptions if the value cannot be parsed into a double. Double.TryParse will never throw an exception, but instead returns a True/False value to indicate of the value was successfully converted or not.
You normally don't check the text representation of number for the correct format first. You try the conversion, and if it works, you then validate the returned number for proper range. If this entire process doesn't work, then your code can throw it's own exception. Seeing if a string will successfully convert to a number, regardless of localization, isn't really practical. You're trying to avoid having the conversion throw an exception, when that should not be your focus. You should be TRYING the conversion, then either throw your own exception if the conversion fails, or returning the validated value of the conversion.
It sounds like you're trying to do the conversion and validation backwards. It's far easier to validate the data in its native type than it is to validate it as a simple string. Convert the data to it's native type first, and if that works, validate the converted value. If that passes, then you've got a good value. But if either of those steps fails, then your conversion code should throw it's own exception.
|
|
|
|
|
Perhaps VB.net's documentation should mention double.tryparse in its section on conversion functions? The double.tryparse sounds very useful.
I certainly agree that trying to process something to see if it works often makes more sense than trying to pre-validate it, especially with things like dates (where validating requires just as much work as doing an actual conversion). I'm a bit paranoid, though, of being bitten because an object throws an exception for a case which is harmless but I don't happen to explicitly handle.
If double.tryparse didn't exist, what problem would there be with a function that called cdbl() and (except for setting a return value) just ignored any exceptions? Is the hazard that there may be exceptions whose consequences go beyond the conversion at hand?
BTW, forgive me if this is a FAQ, but is there a way to handle multiple types of exception within a try/catch block?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
