Variable scope doesn't make sense to me when it comes to Try Catch Finally.
Example: In order to close/dispose a db connection you have to dim the
connection outside of the Try Catch Finally block. But, I prefer to dim them
"on the fly" only if needed (save as much resources as possible). A little
further... I may wish to create a sqlcommand and datareader object ONLY if
certain conditions are met. But, if I want to clean these up in the Finally
then I am FORCED to declare them above the Try.
Why???
23  3054 
Why not declare them and just CREATE them when you need to. After all,
that's what may take the longest.
- Jeff
"VB Programmer" <gr*********@ go-intech.com> wrote in message
news:#$******** ******@TK2MSFTN GP12.phx.gbl... Variable scope doesn't make sense to me when it comes to Try Catch
Finally.
Example: In order to close/dispose a db connection you have to dim the
connection outside of the Try Catch Finally block. But, I prefer to dim
them "on the fly" only if needed (save as much resources as possible). A little
further... I may wish to create a sqlcommand and datareader object ONLY if
certain conditions are met. But, if I want to clean these up in the
Finally then I am FORCED to declare them above the Try.
Why???
Well, you are most of the way there in your description. Variables are local
to the scope they are declared in, and scope is determined by code block.
Any time you have a code block, you can declare local variables in that
block. This is true for try - catch - finally, if, while, or anything other
similar construct. This enables you to declare a new variable inside that
block, and have it marked for GC once you exit that code block.
What it means for you in terms of your try - catch is that you need to code
around how you create it. First of all, declaring a variable doesn't
allocate space for it, so you don't have to worry about that. You may also
want to re-think what you are enclosing in a try-catch block. You don't need
to wrap huge chuck of code in such a block - you just need to wrap a
dangerous operation that might throw an exception in such a block. So,
declare, prepare, then when you execute the risky operation, wrap it in a
try-catch. I seldom have more than a couple of lines of code in a try block,
and usually have exactly one.
--
Chris Jackson
Software Engineer
Microsoft MVP - Windows XP
Windows XP Associate Expert
--
"VB Programmer" <gr*********@ go-intech.com> wrote in message
news:%2******** ********@TK2MSF TNGP12.phx.gbl. .. Variable scope doesn't make sense to me when it comes to Try Catch
Finally.
Example: In order to close/dispose a db connection you have to dim the
connection outside of the Try Catch Finally block. But, I prefer to dim
them "on the fly" only if needed (save as much resources as possible). A little
further... I may wish to create a sqlcommand and datareader object ONLY if
certain conditions are met. But, if I want to clean these up in the
Finally then I am FORCED to declare them above the Try.
Why???
> You mentioned "I seldom have more than a couple of lines of code in a try block, and usually have exactly one." Is this standard? In VB6 I've
always
No, that is not the standard. I, for example, will put all of the code in a
method inside a try/catch block, and then put additional try/catch blocks
and conditional code inside that outer block to catch specific errors. The
outside one is for anything I might have missed. How you use it is up to
you, and what your needs are.
What is considered "risky operation"? Connecting to db, filling datasets,
datareaders, etc...?
That's a difficult question to answer (which is why I wrap all of my method
code in an outer try/catch block). Any operation which might cause your
program to malfunction is risky.
The bottom line is (and everyone here seems to agree on this), declare your
variables outside of the block, and assign them inside the block.
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
http://www.takempis.com
Complex things are made up of
lots of simple things.
"VB Programmer" <gr*********@ go-intech.com> wrote in message
news:%2******** ********@TK2MSF TNGP12.phx.gbl. .. Very interesting response.
You mentioned "I seldom have more than a couple of lines of code in a try
block, and usually have exactly one." Is this standard? In VB6 I've
always coded using "On Error Goto errHandler, etc..." which wraps all the code
into the trap. Do I have to need a paradigm shift? How do I handle errors
outside of the Try statement?
What is considered "risky operation"? Connecting to db, filling datasets,
datareaders, etc...?
"Chris Jackson" <ch****@mvps.or g> wrote in message
news:ek******** *****@TK2MSFTNG P12.phx.gbl... Well, you are most of the way there in your description. Variables are local to the scope they are declared in, and scope is determined by code
block. Any time you have a code block, you can declare local variables in that
block. This is true for try - catch - finally, if, while, or anything
other similar construct. This enables you to declare a new variable inside
that block, and have it marked for GC once you exit that code block.
What it means for you in terms of your try - catch is that you need to
code around how you create it. First of all, declaring a variable doesn't
allocate space for it, so you don't have to worry about that. You may
also want to re-think what you are enclosing in a try-catch block. You don't
need to wrap huge chuck of code in such a block - you just need to wrap a
dangerous operation that might throw an exception in such a block. So,
declare, prepare, then when you execute the risky operation, wrap it in
a try-catch. I seldom have more than a couple of lines of code in a try
block, and usually have exactly one.
--
Chris Jackson
Software Engineer
Microsoft MVP - Windows XP
Windows XP Associate Expert
--
"VB Programmer" <gr*********@ go-intech.com> wrote in message
news:%2******** ********@TK2MSF TNGP12.phx.gbl. .. Variable scope doesn't make sense to me when it comes to Try Catch
Finally.
Example: In order to close/dispose a db connection you have to dim the
connection outside of the Try Catch Finally block. But, I prefer to
dim them "on the fly" only if needed (save as much resources as possible). A
little further... I may wish to create a sqlcommand and datareader object
ONLY if certain conditions are met. But, if I want to clean these up in the
Finally then I am FORCED to declare them above the Try.
Why???
And one other thing I should mention, in case you don't understand. The
problem you experienced was due to referencing variables declared inside the
try/catch block from the Finally block. The Finally block executes
regardless of whether an error occurs or not. That means that it must be
able to access the variables used in it regardless of whether they were
assigned or not. When you declare a variable inside the try block, your code
might never reach the declaration before execution falls through to the
catch block. Therefore, any variable referenced in the Finnally block must
be declared prior to the Try block.
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer http://www.takempis.com
Complex things are made up of
lots of simple things.
"VB Programmer" <gr*********@ go-intech.com> wrote in message
news:%2******** ********@TK2MSF TNGP12.phx.gbl. .. Very interesting response.
You mentioned "I seldom have more than a couple of lines of code in a try
block, and usually have exactly one." Is this standard? In VB6 I've
always coded using "On Error Goto errHandler, etc..." which wraps all the code
into the trap. Do I have to need a paradigm shift? How do I handle errors
outside of the Try statement?
What is considered "risky operation"? Connecting to db, filling datasets,
datareaders, etc...?
"Chris Jackson" <ch****@mvps.or g> wrote in message
news:ek******** *****@TK2MSFTNG P12.phx.gbl... Well, you are most of the way there in your description. Variables are local to the scope they are declared in, and scope is determined by code
block. Any time you have a code block, you can declare local variables in that
block. This is true for try - catch - finally, if, while, or anything
other similar construct. This enables you to declare a new variable inside
that block, and have it marked for GC once you exit that code block.
What it means for you in terms of your try - catch is that you need to
code around how you create it. First of all, declaring a variable doesn't
allocate space for it, so you don't have to worry about that. You may
also want to re-think what you are enclosing in a try-catch block. You don't
need to wrap huge chuck of code in such a block - you just need to wrap a
dangerous operation that might throw an exception in such a block. So,
declare, prepare, then when you execute the risky operation, wrap it in
a try-catch. I seldom have more than a couple of lines of code in a try
block, and usually have exactly one.
--
Chris Jackson
Software Engineer
Microsoft MVP - Windows XP
Windows XP Associate Expert
--
"VB Programmer" <gr*********@ go-intech.com> wrote in message
news:%2******** ********@TK2MSF TNGP12.phx.gbl. .. Variable scope doesn't make sense to me when it comes to Try Catch
Finally.
Example: In order to close/dispose a db connection you have to dim the
connection outside of the Try Catch Finally block. But, I prefer to
dim them "on the fly" only if needed (save as much resources as possible). A
little further... I may wish to create a sqlcommand and datareader object
ONLY if certain conditions are met. But, if I want to clean these up in the
Finally then I am FORCED to declare them above the Try.
Why???
Folks, I cant beleive how long this thread has become !
When we are old and grey, we can enchant our grandchildren with stories of
how we spent our precious youth talking about Try Catch blocks !
Sorry, couldnt resist that, keep smiling :)
"VB Programmer" <gr*********@ go-intech.com> wrote in message
news:%2******** ********@TK2MSF TNGP12.phx.gbl. .. Variable scope doesn't make sense to me when it comes to Try Catch
Finally.
Example: In order to close/dispose a db connection you have to dim the
connection outside of the Try Catch Finally block. But, I prefer to dim
them "on the fly" only if needed (save as much resources as possible). A little
further... I may wish to create a sqlcommand and datareader object ONLY if
certain conditions are met. But, if I want to clean these up in the
Finally then I am FORCED to declare them above the Try.
Why???
Good stuff! :)
"Terry Burns" <te*********@BT Openworld.com> wrote in message
news:OX******** ******@TK2MSFTN GP09.phx.gbl... Folks, I cant beleive how long this thread has become !
When we are old and grey, we can enchant our grandchildren with stories of
how we spent our precious youth talking about Try Catch blocks !
Sorry, couldnt resist that, keep smiling :)
"VB Programmer" <gr*********@ go-intech.com> wrote in message
news:%2******** ********@TK2MSF TNGP12.phx.gbl. .. Variable scope doesn't make sense to me when it comes to Try Catch
Finally.
Example: In order to close/dispose a db connection you have to dim the
connection outside of the Try Catch Finally block. But, I prefer to dim
them "on the fly" only if needed (save as much resources as possible). A
little further... I may wish to create a sqlcommand and datareader object ONLY
if certain conditions are met. But, if I want to clean these up in the
Finally then I am FORCED to declare them above the Try.
Why???
A risky operation is anything that could raise an exception. When calling a
method check the help on it. It will list any exceptions that it raised and
the conditions to cause the exception.
Anytime a risky operation is called place it in the try block, and in the
finally block clean up any resources such as filestreams, database
connections, references to COM objects, etc... In the catch block you
could...
1) propagate the error to the caller
2) wrap that error in a new custom (InnerException ) error of your own giving
a more human understandable message and throw to caller
3) log the error and continue with rest of method
4) ignore and do again (entire try-catch-finally in a loop).
5) ignore the error and continue with rest of method.
6) ?? anything you desire
What you do depends on the needs/requirements of your application.
--
Michael Lang, MCSD
See my .NET open source projects http://sourceforge.net/projects/dbobjecter (code generator) http://sourceforge.net/projects/genadonet ("generic" ADO.NET)
"VB Programmer" <gr*********@ go-intech.com> wrote in message
news:%2******** ********@TK2MSF TNGP12.phx.gbl. .. Very interesting response.
You mentioned "I seldom have more than a couple of lines of code in a try
block, and usually have exactly one." Is this standard? In VB6 I've
always coded using "On Error Goto errHandler, etc..." which wraps all the code
into the trap. Do I have to need a paradigm shift? How do I handle errors
outside of the Try statement?
What is considered "risky operation"? Connecting to db, filling datasets,
datareaders, etc...?
"Chris Jackson" <ch****@mvps.or g> wrote in message
news:ek******** *****@TK2MSFTNG P12.phx.gbl... Well, you are most of the way there in your description. Variables are local to the scope they are declared in, and scope is determined by code
block. Any time you have a code block, you can declare local variables in that
block. This is true for try - catch - finally, if, while, or anything
other similar construct. This enables you to declare a new variable inside
that block, and have it marked for GC once you exit that code block.
What it means for you in terms of your try - catch is that you need to
code around how you create it. First of all, declaring a variable doesn't
allocate space for it, so you don't have to worry about that. You may
also want to re-think what you are enclosing in a try-catch block. You don't
need to wrap huge chuck of code in such a block - you just need to wrap a
dangerous operation that might throw an exception in such a block. So,
declare, prepare, then when you execute the risky operation, wrap it in
a try-catch. I seldom have more than a couple of lines of code in a try
block, and usually have exactly one.
--
Chris Jackson
Software Engineer
Microsoft MVP - Windows XP
Windows XP Associate Expert
--
"VB Programmer" <gr*********@ go-intech.com> wrote in message
news:%2******** ********@TK2MSF TNGP12.phx.gbl. .. Variable scope doesn't make sense to me when it comes to Try Catch
Finally.
Example: In order to close/dispose a db connection you have to dim the
connection outside of the Try Catch Finally block. But, I prefer to
dim them "on the fly" only if needed (save as much resources as possible). A
little further... I may wish to create a sqlcommand and datareader object
ONLY if certain conditions are met. But, if I want to clean these up in the
Finally then I am FORCED to declare them above the Try.
Why???
> > You mentioned "I seldom have more than a couple of lines of code in a
try block, and usually have exactly one." Is this standard? In VB6 I've always
No, that is not the standard. I, for example, will put all of the code in
a method inside a try/catch block, and then put additional try/catch blocks
and conditional code inside that outer block to catch specific errors. The
outside one is for anything I might have missed. How you use it is up to
you, and what your needs are.
I would never go so far as to put all of the code inside of a method inside
of a try-catch block, because then you are never really sure what you are
catching. Sure, you could simply catch a System.Exceptio n, but if you don't
know what you're catching, and as a result can't react appropriately, you
probably don't want to just sit on that error instead of passing it up
through the call stack.
With VB6, you just had to universally set up an onerror statement that
caught all errors, and then go through and figure out what happened and what
to do about it. The beauty of try-catch is that you can wrap specific
statements and handle it appropriately.
Let's do an example - open up a SQL Server connection, set up a command
object, and execute that command object:
----
SqlConnection connMyConnectio n = new SqlConnection(s zConnectionStri ng);
SqlCommand cmdMyCommand = new SqlCommand("MyC ommand", connMyConnectio n);
cmdMyCommand .CommandType = CommandType.Sto redProcedure;
cmdMyCommand .Parameters.Add ("@myParameter" , SqlDbType.VarCh ar, 50).Value =
szValue;
connMyConnectio n.Open();
cmdMyCommand.Ex ecuteNonQuery() ;
----
The SqlConnection constructor that I used does not throw an exception, so
there is nothing to catch there.
The SqlCommand constructor that I used does not throw an exception, so there
is nothing to catch there.
Setting the command type could throw an ArgumentExcepti on, so you'll want to
catch that.
The add method of the parameters collection doesn't throw an exception, nor
does the Value property of the SqlParameter object, so there is nothing to
catch there.
The Open method of SqlConnection could throw either an
InvalidOperatio nException or a SqlException, so you'll want to catch that.
The ExecuteNonQuery method of SqlCommand could throw a SqlException, so
you'll want to catch that.
So, you end up with:
----
SqlConnection connMyConnectio n = new SqlConnection(c onnectionString );
SqlCommand cmdMyCommand = new SqlCommand("MyC ommand", connMyConnectio n);
try {
cmdMyCommand .CommandType = CommandType.Sto redProcedure;
} catch (ArgumentExcept ion myArgumentExcep tion) {
// do something to react to this - since it's hard coded, you can
probably fix your code and get rid of this check
} finally {
// do some cleanup work
}
cmdMyCommand .Parameters.Add ("@myParameter" , SqlDbType.VarCh ar, 50).Value =
szValue;
try {
connMyConnectio n.Open();
} catch (InvalidOperati onException myInvalidOperat ionException) {
// do something to react to this - since it's hard coded, again you can
probably fix your code and dispense with this check
} catch (SqlException mySqlException1 ) {
// do something to react to this - either dump to the event log or, if
in debug mode (use preprocessors) write back the message
} finally {
// do some cleanup work
}
try {
cmdMyCommand.Ex ecuteNonQuery() ;
} catch (SqlException mySqlException2 ) {
// do something to react to this - either dump to the event log or, if
in debug mode (use preprocessors) write back the message
} finally {
// do some cleanup work
}
----
If you look up the best practices, you will find it stated in as many words:
"Use try/finally blocks around code that can potentially generate an
exception and centralize your catch statements in one location. In this way,
the try statement generates the exception, the finally statement closes or
deallocates resources, and the catch statement handles the exception from a
central location."
Full list of best practices here: http://msdn.microsoft.com/library/de...exceptions.asp
So yes, I would beg to differ. I do consider this a standard. It's what I've
been doing in C++ for years now.
Also, you can check for exceptions before they are thrown. If you are going
to close the aforementioned SqlConnection, instead of just using:
connMyConnectio n.Close();
use:
if (connMyConnecti on != null && connMyConnectio n.State !=
ConnectionState .Closed) {
connMyConnectio n.Close();
}
And so it goes.
--
Chris Jackson
Software Engineer
Microsoft MVP - Windows XP
Windows XP Associate Expert
--
> I would never go so far as to put all of the code inside of a method
inside of a try-catch block, because then you are never really sure what you are
catching. Sure, you could simply catch a System.Exceptio n, but if you
don't know what you're catching, and as a result can't react appropriately, you
probably don't want to just sit on that error instead of passing it up
through the call stack.
I'm always sure of what I'm catching, because I use a global error-handler
routine in my outer try/catch block, which logs the Exception message, any
InnerException message, and a Stack trace to the Event Log. This is so that
I can figure out what caused the error and determine how to best handle it
with code.
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
http://www.takempis.com
Complex things are made up of
lots of simple things.
"Chris Jackson" <ch****@mvps.or g> wrote in message
news:uJ******** ******@TK2MSFTN GP12.phx.gbl... You mentioned "I seldom have more than a couple of lines of code in a try block, and usually have exactly one." Is this standard? In VB6 I've
always
No, that is not the standard. I, for example, will put all of the code
in a method inside a try/catch block, and then put additional try/catch
blocks and conditional code inside that outer block to catch specific errors.
The outside one is for anything I might have missed. How you use it is up to
you, and what your needs are.
I would never go so far as to put all of the code inside of a method
inside of a try-catch block, because then you are never really sure what you are
catching. Sure, you could simply catch a System.Exceptio n, but if you
don't know what you're catching, and as a result can't react appropriately, you
probably don't want to just sit on that error instead of passing it up
through the call stack.
With VB6, you just had to universally set up an onerror statement that
caught all errors, and then go through and figure out what happened and
what to do about it. The beauty of try-catch is that you can wrap specific
statements and handle it appropriately.
Let's do an example - open up a SQL Server connection, set up a command
object, and execute that command object:
----
SqlConnection connMyConnectio n = new SqlConnection(s zConnectionStri ng);
SqlCommand cmdMyCommand = new SqlCommand("MyC ommand", connMyConnectio n);
cmdMyCommand .CommandType = CommandType.Sto redProcedure;
cmdMyCommand .Parameters.Add ("@myParameter" , SqlDbType.VarCh ar, 50).Value
= szValue;
connMyConnectio n.Open();
cmdMyCommand.Ex ecuteNonQuery() ;
----
The SqlConnection constructor that I used does not throw an exception, so
there is nothing to catch there.
The SqlCommand constructor that I used does not throw an exception, so
there is nothing to catch there.
Setting the command type could throw an ArgumentExcepti on, so you'll want
to catch that.
The add method of the parameters collection doesn't throw an exception,
nor does the Value property of the SqlParameter object, so there is nothing to
catch there.
The Open method of SqlConnection could throw either an
InvalidOperatio nException or a SqlException, so you'll want to catch that.
The ExecuteNonQuery method of SqlCommand could throw a SqlException, so
you'll want to catch that.
So, you end up with:
----
SqlConnection connMyConnectio n = new SqlConnection(c onnectionString );
SqlCommand cmdMyCommand = new SqlCommand("MyC ommand", connMyConnectio n);
try {
cmdMyCommand .CommandType = CommandType.Sto redProcedure;
} catch (ArgumentExcept ion myArgumentExcep tion) {
// do something to react to this - since it's hard coded, you can
probably fix your code and get rid of this check
} finally {
// do some cleanup work
}
cmdMyCommand .Parameters.Add ("@myParameter" , SqlDbType.VarCh ar, 50).Value
= szValue;
try {
connMyConnectio n.Open();
} catch (InvalidOperati onException myInvalidOperat ionException) {
// do something to react to this - since it's hard coded, again you
can probably fix your code and dispense with this check
} catch (SqlException mySqlException1 ) {
// do something to react to this - either dump to the event log or, if
in debug mode (use preprocessors) write back the message
} finally {
// do some cleanup work
}
try {
cmdMyCommand.Ex ecuteNonQuery() ;
} catch (SqlException mySqlException2 ) {
// do something to react to this - either dump to the event log or, if
in debug mode (use preprocessors) write back the message
} finally {
// do some cleanup work
}
----
If you look up the best practices, you will find it stated in as many
words:
"Use try/finally blocks around code that can potentially generate an
exception and centralize your catch statements in one location. In this
way, the try statement generates the exception, the finally statement closes or
deallocates resources, and the catch statement handles the exception from
a central location."
Full list of best practices here:
http://msdn.microsoft.com/library/de...exceptions.asp
So yes, I would beg to differ. I do consider this a standard. It's what
I've been doing in C++ for years now.
Also, you can check for exceptions before they are thrown. If you are
going to close the aforementioned SqlConnection, instead of just using:
connMyConnectio n.Close();
use:
if (connMyConnecti on != null && connMyConnectio n.State !=
ConnectionState .Closed) {
connMyConnectio n.Close();
}
And so it goes.
--
Chris Jackson
Software Engineer
Microsoft MVP - Windows XP
Windows XP Associate Expert
--
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Roger Redford |
last post by:
Dear experts,
I'm trying to learn java on my own. I picked up a
sample online, but it is not compiling right:
------------------------------------------------
import java.io.*;
|
by: RepStat |
last post by:
If I have code such a
SqConnection cndb = new SqlConnection(connstr)
SqlDataReader dr = null
tr
cndb.Open()
SqlCommand cmd = new SqlCommand("exec mysp", cndb)
dr = cmd.ExecuteReader()
|
by: Sean Kirkpatrick |
last post by:
I got caught with my pants down the other day when trying to explain
Try...Catch...Finally and things didn't work as I had assumed. Perhaps
someone can explain to me the purpose of Finally. I've looked at several
texts that I have and none of them address this specific point.
If I call some method that throws an exception in my routine Foo,...
|
by: Rob Meade |
last post by:
Hi all,
Ok - typically, in a function that returns as a boolean, if there's a bit of
database action going on I'll have a little tidy up process before exiting
the function.
I know .net is supposed to handle all of this stuff itself, but its a
practice I've always performed, and personally I like to know its been done!
So, as an...
|
by: foolmelon |
last post by:
If a childThread is in the middle of a catch block and handling an
exception caught, the main thread calls childThread.Abort(). At that
time a ThreadAbortException is thrown in the childThread. The question
is: after the ThreadAbortException is thrown, does the childThread
continue run the remaining code in the catch block?
| | |
by: Morten Snedker |
last post by:
The use of Try in the Finally part - is that overkill?. I think of the
code failing before opening sqlCon - that would generate an error in
the Finally part. How would Finally handle that?
Try
Dim cmd As New SqlCommand
cmd.CommandText = "spSetAdLinks"
cmd.CommandType = Data.CommandType.StoredProcedure
cmd.Connection = sqlCon
|
by: =?Utf-8?B?aGVyYmVydA==?= |
last post by:
I read from a serialport using a worker thread. Because the worker thread t
does not loop often, I cannot wait to terminate the worker thread using a
boolean in the While condition.
So I have a StopReader() method that simply aborts the worker thread (is
there a better way for the above situation?).
The StopReader creates an...
|
by: David Lozzi |
last post by:
Howdy,
I ran into a very interesting issue and I'm curios as to how this is suppose
to work. I am using Try...Catch...Finally statements for all database
connectivity in my ASP.NET 2.0 web application. I'm connecting to IBM's
Universe 10.2 using UniObjects.Net. Anyway, if the connection errors, the
Finally closes the connection. What I see...
|
by: TC |
last post by:
Hey All,
I posted this to the Crypto users group and forgot to add the VB.Net users
group. I apologize for any confusion.
I have been testing a try / catch / finally block and purposely raising
exceptions and I've noticed that if an exception of "Length of the data to
decrypt is invalid." is raised with the CryptoStream object, later...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it. ...
| | |
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules.
He will explain when you may want to use classes...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one.
At the time of converting from word file to html my equations which are in the word document file was convert...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols.
I succeeded, with both firewalls in...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
| | |
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| |
