473,746 Members | 2,311 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Is David Fenton right about error handling? (re-post?)

(sorry for the likely repost, but it is still not showing on my news server
and after that much typing, I don't want to lose it)
I am considering general error handling routines and have written a sample
function to look up an ID in a table. The function returns True if it can
find the ID and create a recordset based on that ID, otherwise it returns
false.

**I am not looking for comments on the usefulness of this function - it is
only to demonstrate error handling**

There are three versions of this code. David Fenton says under the earlier
thread "DAO peculiarity in A97?" that version 1 is bad since it has multiple
lines covered by On Error Resume Next and that a danger exists of this
'spilling over' into another block of code. Can anyone demonstrate this?
Do others have experience of this happening?
It seems he would prefer version 2. But I am wondering - if I cannot rely
on the error handling to be reset when I exit my function, can I guarantee
there is zero possibility of an error in the Exit_Handler part in version 2?
(e.g. the recordset wasn't nothing, but trying to close it causes an error).
If there is an error in the Exit_Handler part, we obviously get stuck in a
never-ending loop, so to some extent it would make sense to make sure that
this cannot happen. The code is also less verbose, particularly when there
are many objects to be cleared up. Perhaps the answer is version 3 which
tacks on a final 'On Error GoTo 0' but I have never seen anyone write a
function with that type of error handling.

**I am undecided and seeking the group's opinions**

Public Function ContactExists1( lngConID As Long) As Boolean

On Error GoTo Err_Handler

Dim dbs As DAO.Database
Dim rst As DAO.Recordset
Dim strSQL As String

strSQL = "SELECT tblContact.* FROM tblContact WHERE " & _
"ConID=" & CStr(lngConID)

Set dbs = CurrentDb

Set rst = dbs.OpenRecords et(strSQL, dbOpenForwardOn ly, dbReadOnly)

If Not rst.EOF Then
ContactExists1 = True
End If

Exit_Handler:
On Error Resume Next
rst.Close
Set rst = Nothing
Set dbs = Nothing
Exit Function

Err_Handler:
MsgBox Err.Description , vbExclamation, "Error No: " & Err.Number
Resume Exit_Handler

End Function

Public Function ContactExists2( lngConID As Long) As Boolean

On Error GoTo Err_Handler

Dim dbs As DAO.Database
Dim rst As DAO.Recordset
Dim strSQL As String

strSQL = "SELECT tblContact.* FROM tblContact WHERE " & _
"ConID=" & CStr(lngConID)

Set dbs = CurrentDb

Set rst = dbs.OpenRecords et(strSQL, dbOpenForwardOn ly, dbReadOnly)

If Not rst.EOF Then
ContactExists2 = True
End If

Exit_Handler:

If Not rst Is Nothing Then
rst.Close
Set rst = Nothing
End If

If Not dbs Is Nothing Then
Set dbs = Nothing
End If

Exit Function

Err_Handler:
MsgBox Err.Description , vbExclamation, "Error No: " & Err.Number
Resume Exit_Handler

End Function

Public Function ContactExists3( lngConID As Long) As Boolean

On Error GoTo Err_Handler

Dim dbs As DAO.Database
Dim rst As DAO.Recordset
Dim strSQL As String

strSQL = "SELECT tblContact.* FROM tblContact WHERE " & _
"ConID=" & CStr(lngConID)

Set dbs = CurrentDb

Set rst = dbs.OpenRecords et(strSQL, dbOpenForwardOn ly, dbReadOnly)

If Not rst.EOF Then
ContactExists3 = True
End If

Exit_Handler:
On Error Resume Next
rst.Close
Set rst = Nothing
Set dbs = Nothing
On Error GoTo 0
Exit Function

Err_Handler:
MsgBox Err.Description , vbExclamation, "Error No: " & Err.Number
Resume Exit_Handler

End Function

Jan 3 '06 #1
10 2291
"Anthony England" <ae******@oops. co.uk> wrote in
news:dp******** **@nwrdmz01.dmz .ncs.ea.ibs-infra.bt.com:
(sorry for the likely repost, but it is still not showing on my
news server and after that much typing, I don't want to lose it)
I am considering general error handling routines and have written
a sample function to look up an ID in a table. The function
returns True if it can find the ID and create a recordset based on
that ID, otherwise it returns false.

**I am not looking for comments on the usefulness of this function
- it is only to demonstrate error handling**

There are three versions of this code. David Fenton says under
the earlier thread "DAO peculiarity in A97?" that version 1 is bad
since it has multiple lines covered by On Error Resume Next and
that a danger exists of this 'spilling over' into another block of
code. Can anyone demonstrate this?
Even *I* can't demonstrate it.

However, I had an app that had problems that could only be explained
by the use of On Error Resume Next. When those were removed (or
allowed to apply to only one line at a time), the problems with data
errors being lost disappeared. This was several years ago.

Now, philosophically , I have a definite problem with relying on it.
It's lazy programming, in my opinion.

Using it shows that you *know* an error is going to happen. To me,
that shows that, instead of saying "ignore the error" you should
trap for it and respond accordingly.

The main reason for this is that you can't anticipate every possible
error, and there could be errors that you *don't* want to ignore
(which is what was happening in the app I cited above).

This is, of course, separate from the issue of scope, which I can't
really prove. All I know is that it appeared to me that On Error
Resume Next was not going out of scope when subroutines ended.
Do others have experience of this happening?
It seems he would prefer version 2. But I am wondering - if I
cannot rely on the error handling to be reset when I exit my
function, can I guarantee there is zero possibility of an error in
the Exit_Handler part in version 2? (e.g. the recordset wasn't
nothing, but trying to close it causes an error). If there is an
error in the Exit_Handler part, we obviously get stuck in a
never-ending loop, so to some extent it would make sense to make
sure that this cannot happen. The code is also less verbose,
particularly when there are many objects to be cleared up.
Perhaps the answer is version 3 which tacks on a final 'On Error
GoTo 0' but I have never seen anyone write a function with that
type of error handling.


I don't know what errors could happen in closing a recordset. If you
are avoiding doing it my way because of a worry about an unforeseen
error, then it seems to me to be contradictory of your seeming
preference for a method that ignores *all* errors, anticipated or
not. In other words, you seem to prefer a method that ignores *all*
unforeseen errors to a method that may break if *one* unforeseen
error occurs.

That seems extremely unwise to me.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Jan 3 '06 #2
"David W. Fenton" <XX*******@dfen ton.com.invalid > wrote in message
news:Xn******** *************** ***********@127 .0.0.1...
"Anthony England" <ae******@oops. co.uk> wrote in
news:dp******** **@nwrdmz01.dmz .ncs.ea.ibs-infra.bt.com:
However, I had an app that had problems that could only be explained
by the use of On Error Resume Next. When those were removed (or
allowed to apply to only one line at a time), the problems with data
errors being lost disappeared. This was several years ago.

Now, philosophically , I have a definite problem with relying on it.
It's lazy programming, in my opinion.

Do others have experience of this happening?
It seems he would prefer version 2. But I am wondering - if I
cannot rely on the error handling to be reset when I exit my
function, can I guarantee there is zero possibility of an error in
the Exit_Handler part in version 2? (e.g. the recordset wasn't
nothing, but trying to close it causes an error). If there is an
error in the Exit_Handler part, we obviously get stuck in a
never-ending loop, so to some extent it would make sense to make
sure that this cannot happen. The code is also less verbose,
particularly when there are many objects to be cleared up.
Perhaps the answer is version 3 which tacks on a final 'On Error
GoTo 0' but I have never seen anyone write a function with that
type of error handling.


I don't know what errors could happen in closing a recordset. If you
are avoiding doing it my way because of a worry about an unforeseen
error, then it seems to me to be contradictory of your seeming
preference for a method that ignores *all* errors, anticipated or
not. In other words, you seem to prefer a method that ignores *all*
unforeseen errors to a method that may break if *one* unforeseen
error occurs.

That seems extremely unwise to me.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/


I had a problem similar to the one David describes with On Error Resume
Next. It was particularly bad because I let it get out to a customer that
way (shame on me). It caused some highly intermittent problems that were
extremely difficult to pin down. It was several years ago and I no longer
have the code.

I also agree that its use is "lazy programming" but I still use it on
occasion. Properly trapping errors is always better, but I'm a lazy
programmer. The solution that I've come up with is to never, ever leave a
section of code with On Error Resume Next "unterminat ed". I consider On
Error Goto 0 (or Goto something else) a proper termination. I used to put
Err.Clear ahead of the Goto, but that didn't seem to make any difference.
Also, keep blocks of code with Resume Next as small as possible and be very
certain that code that doesn't get run and doesn't generate an error can't
cause problems elsewhere. This "solution" has worked well for me.

--
Randy Harris
tech at promail dot com
I'm pretty sure I know everything that I can remember.
Jan 3 '06 #3
Another perspective: I sometimes trap for particular errors that I want
to do special processing with, then use Resume Next after that
processing so the user never sees any error I don't want them to. As
David said, some errors shouldn't be ignored, but at the same time I'd
rather keep frivolous errors from popping up than show every error.
Note that it would be difficult to trap EVERY possible error that is
not terribly important, or rather it would take a lot of code.

Jan 3 '06 #4
"David W. Fenton" <XX*******@dfen ton.com.invalid > wrote in message
news:Xn******** *************** ***********@127 .0.0.1...
"Anthony England" <ae******@oops. co.uk> wrote in
news:dp******** **@nwrdmz01.dmz .ncs.ea.ibs-infra.bt.com:
(sorry for the likely repost, but it is still not showing on my
news server and after that much typing, I don't want to lose it)
I am considering general error handling routines and have written
a sample function to look up an ID in a table. The function
returns True if it can find the ID and create a recordset based on
that ID, otherwise it returns false.

**I am not looking for comments on the usefulness of this function
- it is only to demonstrate error handling**

There are three versions of this code. David Fenton says under
the earlier thread "DAO peculiarity in A97?" that version 1 is bad
since it has multiple lines covered by On Error Resume Next and
that a danger exists of this 'spilling over' into another block of
code. Can anyone demonstrate this?


Even *I* can't demonstrate it.

However, I had an app that had problems that could only be explained
by the use of On Error Resume Next. When those were removed (or
allowed to apply to only one line at a time), the problems with data
errors being lost disappeared. This was several years ago.

Now, philosophically , I have a definite problem with relying on it.
It's lazy programming, in my opinion.

Using it shows that you *know* an error is going to happen. To me,
that shows that, instead of saying "ignore the error" you should
trap for it and respond accordingly.

The main reason for this is that you can't anticipate every possible
error, and there could be errors that you *don't* want to ignore
(which is what was happening in the app I cited above).

This is, of course, separate from the issue of scope, which I can't
really prove. All I know is that it appeared to me that On Error
Resume Next was not going out of scope when subroutines ended.
Do others have experience of this happening?
It seems he would prefer version 2. But I am wondering - if I
cannot rely on the error handling to be reset when I exit my
function, can I guarantee there is zero possibility of an error in
the Exit_Handler part in version 2? (e.g. the recordset wasn't
nothing, but trying to close it causes an error). If there is an
error in the Exit_Handler part, we obviously get stuck in a
never-ending loop, so to some extent it would make sense to make
sure that this cannot happen. The code is also less verbose,
particularly when there are many objects to be cleared up.
Perhaps the answer is version 3 which tacks on a final 'On Error
GoTo 0' but I have never seen anyone write a function with that
type of error handling.


I don't know what errors could happen in closing a recordset. If you
are avoiding doing it my way because of a worry about an unforeseen
error, then it seems to me to be contradictory of your seeming
preference for a method that ignores *all* errors, anticipated or
not. In other words, you seem to prefer a method that ignores *all*
unforeseen errors to a method that may break if *one* unforeseen
error occurs.

That seems extremely unwise to me.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Thank you for your response. I am not advocating one approach or the other,
merely asking for input and experiences from others.
You may have missed the central point of my question - and it is not about
cutting corners to be lazy. I am talking specifically about the 'clean up
and exit' part of the function where any error would get us into a
never-ending loop. What you seem to be saying is:
"You cannot guarantee that On Error Resume Next will be 'switched off' when
you leave the function, but you can guarantee that the clean up code will
never ever result in an error being produced (resulting in the ghastly
loop)"

I understand that you cannot give an example of this happening, but am
prepared to believe something like this might happen on some occasions, yet
at the same time like the general idea that the 'clean up and exit' part of
the function always exits.

Would anyone like to comment on version 3, or stick their necks out and
write the best exit-function bit?
Jan 3 '06 #5

"Randy Harris" <ra***@SpamFree .com> wrote in message
news:XD******** ***********@new ssvr21.news.pro digy.com...
"David W. Fenton" <XX*******@dfen ton.com.invalid > wrote in message
news:Xn******** *************** ***********@127 .0.0.1...
"Anthony England" <ae******@oops. co.uk> wrote in
news:dp******** **@nwrdmz01.dmz .ncs.ea.ibs-infra.bt.com:
However, I had an app that had problems that could only be explained
by the use of On Error Resume Next. When those were removed (or
allowed to apply to only one line at a time), the problems with data
errors being lost disappeared. This was several years ago.

Now, philosophically , I have a definite problem with relying on it.
It's lazy programming, in my opinion.

> Do others have experience of this happening?
> It seems he would prefer version 2. But I am wondering - if I
> cannot rely on the error handling to be reset when I exit my
> function, can I guarantee there is zero possibility of an error in
> the Exit_Handler part in version 2? (e.g. the recordset wasn't
> nothing, but trying to close it causes an error). If there is an
> error in the Exit_Handler part, we obviously get stuck in a
> never-ending loop, so to some extent it would make sense to make
> sure that this cannot happen. The code is also less verbose,
> particularly when there are many objects to be cleared up.
> Perhaps the answer is version 3 which tacks on a final 'On Error
> GoTo 0' but I have never seen anyone write a function with that
> type of error handling.


I don't know what errors could happen in closing a recordset. If you
are avoiding doing it my way because of a worry about an unforeseen
error, then it seems to me to be contradictory of your seeming
preference for a method that ignores *all* errors, anticipated or
not. In other words, you seem to prefer a method that ignores *all*
unforeseen errors to a method that may break if *one* unforeseen
error occurs.

That seems extremely unwise to me.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/


I had a problem similar to the one David describes with On Error Resume
Next. It was particularly bad because I let it get out to a customer that
way (shame on me). It caused some highly intermittent problems that were
extremely difficult to pin down. It was several years ago and I no longer
have the code.

I also agree that its use is "lazy programming" but I still use it on
occasion. Properly trapping errors is always better, but I'm a lazy
programmer. The solution that I've come up with is to never, ever leave a
section of code with On Error Resume Next "unterminat ed". I consider On
Error Goto 0 (or Goto something else) a proper termination. I used to put
Err.Clear ahead of the Goto, but that didn't seem to make any difference.
Also, keep blocks of code with Resume Next as small as possible and be
very
certain that code that doesn't get run and doesn't generate an error can't
cause problems elsewhere. This "solution" has worked well for me.

--
Randy Harris
tech at promail dot com
I'm pretty sure I know everything that I can remember.

Hi Randy. Thanks for the response. Your mention of Err.Clear prompted me
to re-read the help file which clearly states that the method is called
after the Exit Function. But I guess if you couldn't rely on one, then you
couldn't rely on the other.

' =============== =============== =============== =====
' ====== Acc XP Help File =============== =============== =
Clear Method

Clears all property settings of the Err object.

Syntax

object.Clear

The object is always the Err object.

Remarks

Use Clear to explicitly clear the Err object after an error has been
handled, for example, when you use deferred error handling with On Error
Resume Next. The Clear method is called automatically whenever any of the
following statements is executed:

Any type of Resume statement
Exit Sub, Exit Function, Exit Property
Any On Error statement
Note The On Error Resume Next construct may be preferable to On Error GoTo
when handling errors generated during access to other objects. Checking Err
after each interaction with an object removes ambiguity about which object
was accessed by the code. You can be sure which object placed the error code
in Err.Number, as well as which object originally generated the error (the
object specified in Err.Source).
Jan 3 '06 #6

"Anthony England" <ae******@oops. co.uk> wrote in message
news:dp******** **@nwrdmz01.dmz .ncs.ea.ibs-infra.bt.com...


Hi Randy. Thanks for the response. Your mention of Err.Clear prompted me
to re-read the help file which clearly states that the method is called
after the Exit Function. But I guess if you couldn't rely on one, then you couldn't rely on the other.

' =============== =============== =============== =====
' ====== Acc XP Help File =============== =============== =
Clear Method

Clears all property settings of the Err object.

Syntax

object.Clear

The object is always the Err object.

Remarks

Use Clear to explicitly clear the Err object after an error has been
handled, for example, when you use deferred error handling with On Error
Resume Next. The Clear method is called automatically whenever any of the
following statements is executed:

Any type of Resume statement
Exit Sub, Exit Function, Exit Property
Any On Error statement
Note The On Error Resume Next construct may be preferable to On Error GoTo when handling errors generated during access to other objects. Checking Err after each interaction with an object removes ambiguity about which object
was accessed by the code. You can be sure which object placed the error code in Err.Number, as well as which object originally generated the error (the
object specified in Err.Source).


Sorry, I didn't make that very clear. I didn't mean to suggest that
Err.Clear was unreliable. The nightmare I mentioned, that I ran into a while
back, was caused by assuming that On Error Resume Next would cleanly go out
of scope. Tracking that problem down cost me a lot of unproductive time and
a lot of embarrassment with a customer. (I couldn't explain the bizarre
problems the app was having). I've never run into a similar situation using
On Error Goto 0.

IMO - It is not uncommon to hide errors from the user, but, a well written
application should never let the user see an unhandled error. I wish I
could say that were true of all my apps.

--
Randy Harris
tech at promail dot com
I'm pretty sure I know everything that I can remember.
Jan 4 '06 #7
"Anthony England" <ae******@oops. co.uk> wrote in
news:dp******** **@nwrdmz03.dmz .ncs.ea.ibs-infra.bt.com:
What you seem to be saying is:
"You cannot guarantee that On Error Resume Next will be 'switched
off' when you leave the function, but you can guarantee that the
clean up code will never ever result in an error being produced
(resulting in the ghastly loop)"
No, I'm not saying that.

I'm saying that you're describing a choice between knowingly
ignoring all errors, including unanticipated ones, and an
alternative that handles the anticipated errors, but could perhaps
get into a loop *if* an error happens in the exit routine. You are
correct, I think, that the only likely line for errors to happen is
the rst.Close line, but I can't conceive of exactly what could cause
an error to happen on that line.

So, it's comparing a nearly inconceivable error that might get you
into a loop to an approach that will knowingly ignore any unforeseen
error.

I definitely prefer taking my chances with the unforeseen error,
since if it happens once, it can then be trapped for.
I understand that you cannot give an example of this happening,
but am prepared to believe something like this might happen on
some occasions, yet at the same time like the general idea that
the 'clean up and exit' part of the function always exits.


I don't know that it does, and didn't say that it did.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Jan 4 '06 #8

"Randy Harris" <ra***@SpamFree .com> wrote in message
news:IB******** ********@newssv r11.news.prodig y.com...

"Anthony England" <ae******@oops. co.uk> wrote in message
news:dp******** **@nwrdmz01.dmz .ncs.ea.ibs-infra.bt.com...


Hi Randy. Thanks for the response. Your mention of Err.Clear prompted
me
to re-read the help file which clearly states that the method is called
after the Exit Function. But I guess if you couldn't rely on one, then

you
couldn't rely on the other.

' =============== =============== =============== =====
' ====== Acc XP Help File =============== =============== =
Clear Method

Clears all property settings of the Err object.

Syntax

object.Clear

The object is always the Err object.

Remarks

Use Clear to explicitly clear the Err object after an error has been
handled, for example, when you use deferred error handling with On Error
Resume Next. The Clear method is called automatically whenever any of the
following statements is executed:

Any type of Resume statement
Exit Sub, Exit Function, Exit Property
Any On Error statement
Note The On Error Resume Next construct may be preferable to On Error

GoTo
when handling errors generated during access to other objects. Checking

Err
after each interaction with an object removes ambiguity about which
object
was accessed by the code. You can be sure which object placed the error

code
in Err.Number, as well as which object originally generated the error
(the
object specified in Err.Source).


Sorry, I didn't make that very clear. I didn't mean to suggest that
Err.Clear was unreliable. The nightmare I mentioned, that I ran into a
while
back, was caused by assuming that On Error Resume Next would cleanly go
out
of scope. Tracking that problem down cost me a lot of unproductive time
and
a lot of embarrassment with a customer. (I couldn't explain the bizarre
problems the app was having). I've never run into a similar situation
using
On Error Goto 0.

IMO - It is not uncommon to hide errors from the user, but, a well written
application should never let the user see an unhandled error. I wish I
could say that were true of all my apps.

--
Randy Harris
tech at promail dot com
I'm pretty sure I know everything that I can remember.

Hmmm... difficult to say whether we are talking about genuine weirdness
going on, or the programmer not remembering that there some subtleties with
error handling. For example, the sub CauseAnError has no error handling and
would normally generate a runtime error, but when I click the button to call
the routine, I do not notice the error.

Private Sub CauseAnError()
' Cause an error with absolutely
' no error handling at all
Eval "1/0"
End Sub

Private Sub cmdTest_Click()
On Error Resume Next
MsgBox "The next sub will cause an error"
Call CauseAnError
MsgBox "Did you notice it?"
End Sub

I hope that none of you would expect an error to be triggered or maintain
that this is some weird buggy feature of 'On Error Resume Next' not going
out of scope when it should.
I am not accusing anyone of mis-understanding this and accept things might
not work as they should - it's just a shame that no-one can show an example
of code which doesn't work as it should with regard to error handling.
Jan 4 '06 #9
Bri
Anthony England wrote:
Hmmm... difficult to say whether we are talking about genuine weirdness
going on, or the programmer not remembering that there some subtleties with
error handling. For example, the sub CauseAnError has no error handling and
would normally generate a runtime error, but when I click the button to call
the routine, I do not notice the error.

Private Sub CauseAnError()
' Cause an error with absolutely
' no error handling at all
Eval "1/0"
End Sub

Private Sub cmdTest_Click()
On Error Resume Next
MsgBox "The next sub will cause an error"
Call CauseAnError
MsgBox "Did you notice it?"
End Sub

I hope that none of you would expect an error to be triggered or maintain
that this is some weird buggy feature of 'On Error Resume Next' not going
out of scope when it should.
I am not accusing anyone of mis-understanding this and accept things might
not work as they should - it's just a shame that no-one can show an example
of code which doesn't work as it should with regard to error handling.


A routine that does not have an error handler passes the error up the
chain to the calling routine, if there is one, to handle the error. So
in your case, CauseAnError errors and pops back to cmdTest_Click to let
it handle it, which it does by ignoring it since you used On Error
Resume Next

--
Bri

Jan 4 '06 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

33
3155
by: Anthony England | last post by:
I am considering general error handling routines and have written a sample function to look up an ID in a table. The function returns True if it can find the ID and create a recordset based on that ID, otherwise it returns false. **I am not looking for comments on the usefulness of this function - it is only to demonstrate error handling** There are three versions of this code. David Fenton says under the earlier thread "DAO...
0
9516
Oralloy
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. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
9351
jinu1996
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 captivates audiences and drives business growth. The Art of Business Website Design Your website is...
1
9286
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
9219
tracyyun
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 choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
8229
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
1
6774
isladogs
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 instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
4587
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 the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
0
4840
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
2
2768
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.