|
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?
|
|
|
|
|
Try
.
. (code)
.
Catch fnfE As FileNotFoundException
' handle FNF case
Catch dnfE As DirectoryNotFoundException
' handle DNF case
Catch ioE As IOException
' handle general IO exception
Catch ex As Exception
' Rethrow anything else that happens
Throw ex
Finally
' any cleanup code that must execute no matter what happens goes here
End Try
|
|
|
|
|
If several cases use the same code, is there any way to consolidate them?
|
|
|
|
|
ADO.NET maintains an open connection to the server, even if your code closed it. This is so that the next connection that uses the same connection string can be made faster without having to rebuild the entire connection with the SQL server. This is called "connection pooling".
If the "closed" connection in the pool goes unused, it will eventually be dropped. I think the default is 15 seconds, afterwhich the connection is SCHEDULED to be dropped. It might not drop right away.
You can force the connection to be dropped yourself if you call the ClearPool method after you close your connection:
Dim conn As New SqlConnection(...)
.
. Do your database query stuff...
.
conn.Close()
conn.ClearPool()
Or you can specify the Pooling option in the connection string to tell ADO.NET not to pool that connection:
Persist Security Info=False;Initial Catalog=Northwind;server=SomeServer; Pooling=False
|
|
|
|
|
Brain oerating very slowly today, may need more coffee or something but in the mean time I am receiving a byte from a piece of hardware something like "1A" I need to reanslate it to 01.10, for a revision, got a slick way of doing it without masking off bits and such? This woudl be in Visual Basic 6
M
|
|
|
|
|
If you're receiving that byte as a byte and not a string, then you have to do the math (masking) to get the nibbles you want. If a string, it's simple string manipulation functions. There is no "slick" way of doing this.
|
|
|
|
|
Not slick, perhaps, but ((i \ 16).ToString & "." & (i Mod 16)) doesn't seem too bad, does it?
|
|
|
|
|
It depends on how the data is comming into his app, either a real byte or a string. If it's a real byte, then yes, it works. If it's a string that just looks like "1A, then it won't work.
Also, he's using VB6, so ToString is out of the question. I also can't remember if "\" is a valid operator in VB6. It is in VB.NET.
|
|
|
|
|
The "\" operator does exist in VB6. Very useful, especially since VB6 real->integer coercion rounds rather than truncates.
The VB6 str() function will convert a number to a string, but adds a leading blank if the number is positive. I think cstr() or cstring() will convert without the leading blank.
BTW, is there any good built-in function to convert an integer to a two, four, or eight-digit hex string? It would be nice if the hex() function allowed one to specify the number of digits, but alas it seems not to.
Incidentally, a warning for people using "val()" to convert hex data to long: using val("&h" & string) will yield bogus results with values in the range "00008000" to "0000FFFF". You must use val("&h" & string & "&").
|
|
|
|
|
supercat9 wrote: BTW, is there any good built-in function to convert an integer to a two, four, or eight-digit hex string?
No, there isn't. Hex will return a string of the minimum length required to display the converted number. It's easy enough to build a function though. All you have to do is pass in the value and the number of digits you want, then use Hex to convert the value to it's Hex representation, create a string with the proper number of 0's in it minus the length of the Hex string and stich the two together.
|
|
|
|
|
It's easy enough to build a function though.
That's what I've done and can continue to do (defining hex2, hex4, and hex8 functions). I didn't want to reinvent the wheel if it had already been done, especially since computing hex8 requires generating three temporary strings. Probably not a huge performance hit, but not exactly elegant, especially since such functions are needed often enough they should have been in VB in the first place.
|
|
|
|
|
supercat9 wrote: (defining hex2, hex4, and hex8 functions).
Why?? Why not just write a single function that take the number of places as a parameter??
supercat9 wrote: since computing hex8 requires generating three temporary strings
Why?
|
|
|
|
|
\ is a valid operator in vb6
|
|
|
|
|
It's been sooooo long since I've touched VB6. Thankfully...
|
|
|
|
|
ya i still have to on occasion 
In the past I used it to know if a number was even.
If Val \ 2 = Val / 2 Then
'even
Else
'odd
End If
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
