|
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
|
|
|
|
|
When my programme starts I first display a login screen and then if the right user and pass are entered I open my main screen.
Untill now I'v been hiding the login screen (and it works fine) but I would like to close it.
Since this screen opens another form it gives an error:
An attempt has been made to free an RCW that is in use. The RCW is in use on the active thread or another thread. Attempting to free an in-use RCW can cause corruption or data loss.
anyone know how I can close the login screen (who is the startup form) and open another form.
I don't want to open my main form and open the login ontop (showdialog).
any help will be apriciated
If my help was helpfull let me know, if not let me know why.
The only way we learn is by making mistakes.
|
|
|
|
|
Don't make your Login form the startup form. Instead, create your own Sub Main and set your applications startup object to that.
In there, you'll launch your login form where you get the user credentials and authenticate them. Your form should then kill itself (Application.Exit) returning control to your Sub Main.
In your login form, you can expose some properties that tell if the user was successfully authenticated and a property or two identifying the user.
In your main application form, you can create a Sub New that takes the user credentials as parameters, or whatever else you want.
<STAThread()> _
Shared Sub Main()
Dim loginForm As New LoginForm()
Application.Run(loginForm)
If loginForm.Authenticated Then
Dim myApp As New MainForm(loginForm.Credentials)
Application.Run(myApp)
End If
End Sub
|
|
|
|
|
I'm developing a programme where the user needs to login.
How it should work:
the programme starts and makes a connection to the db (with a standard user and pass) reads the table users and puts that table into a datatable.
once the user has provided his login and pass (and they exist) a new connection to the db is made with the his login and pass (they are created in SQL server), after this only the users connection is used to access the db (that way we can always know who is connected)
this all works and the programme works fine but when I check the connections to the db (in SQL server) it says that there are still 2 connections (per user). Now I don't like this since this programme is going to be used by 10+ users that would mean there are already 20+ connections (I know that that is now problem for SQL but it just isn't how it is supposed to work) and there are also many other db's hosted onto the server so the less connections the better.
following is the code that I use to get the users from the db:
Public Shared Function ExecSqlInDatatable(ByVal Sql As String, ByVal connstring As String) As DataTable
Dim dt As New DataTable
Try
Dim da As New SqlDataAdapter(Sql, connstring)
da.Fill(dt)
'da.Dispose()
'da = Nothing
Return dt
Catch ex As Exception
MessageBox.Show(ex.Message)
End Try
Return dt
End Function
this code works but the connection to the db is maintained.
Any idea why??
Adding the da.dispose and da = nothing didn't help (that's why they are in comment)
any help/idea would be appriciated
If my help was helpfull let me know, if not let me know why.
The only way we learn is by making mistakes.
|
|
|
|
|
TDDragon wrote: this all works and the programme works fine but when I check the connections to the db (in SQL server) it says that there are still 2 connections (per user).
Yes, it is the connection pooling. It is faster to get an existing connection out of the pool than create a new one, so once a connection is created for the first time it will be returned to the pool once it is finished with.
TDDragon wrote: Now I don't like this since this programme is going to be used by 10+ users that would mean there are already 20+ connections (I know that that is now problem for SQL but it just isn't how it is supposed to work) and there are also many other db's hosted onto the server so the less connections the better.
It sounds like what you actually need is some sort of service interface to sit between your application and SQL Server (in order that you are only using one pool of connections to the database). If performance isn't so critical you can look at turning the pooling off (Not something I can remember how to do - it's been a few years since I last looked at that)
|
|
|
|
|
How read a barcode from scaner?
Plz Help me.
|
|
|
|
|
Hi
You Need an object that connect to barcode device
and usually have an event for alert to you when action.
that object Depend on device
you would provide that from manofactor of device
contact by barcode company
|
|
|
|
|
You need to consult the documentation of the scanner to figure this out. See if there is an SDK available for your scanner and read the documention on it if there is one.
|
|
|
|
|
Barcode scanners normally work like a normal keyboard, you just need to trap the event for 'Enter' being pressed in your textbox (or whichever control you're using), which is sent after the end character of the barcode is scanned.
I'm not saying it works for all scanners, though it has in the one's I have tried
|
|
|
|
|
Yeah, I know that. I also know that he hasn't specified anything about which scaner he's using. It could be a keyboard wedge, serial, USB, or ethernet based unit, only about half of which act like a keyboard.
|
|
|
|