I have a method in my base class that I want ALL derived classes to use.
But, I find that I can create a "Shadow" method in my derived class that
"overrides" the method in my base class. Can't figure out what attribute to
put on the base class method to prevent this.
TIA,
Larry Woods
9  1803 
Larry,
The only "sure fire" way to prevent a subclass from using Shadow on a method
is to prevent the sub class in the first place via the NotInheritable
keyword.
Considering one of the main reasons for Shadows is to prevent changes in new
versions of base classes from breaking existing subclasses, I think not
having an attribute is more of a good thing then a bad thing. Otherwise
class libraries could release new versions, that had such an attribute and
suddenly break existing code!
What you can do in your code is assign your object to a variable of your
base type, then call you method, assuming the method is not overridable, you
are guaranteed that your version will be called and not the Shadowed
version.
Hope this helps
Jay
"Larry Woods" <la***@lwoods.c om> wrote in message
news:u5******** ******@TK2MSFTN GP10.phx.gbl... I have a method in my base class that I want ALL derived classes to use.
But, I find that I can create a "Shadow" method in my derived class that
"overrides" the method in my base class. Can't figure out what attribute
to put on the base class method to prevent this.
TIA,
Larry Woods
Thanks, Jay.
Looks like Shadow is a "feature" I could do without. Seems to pretty much
eliminates the possibility for guaranteeing the encapsulation of code in a
base class, right?
Larry
"Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in message
news:e7******** ******@TK2MSFTN GP11.phx.gbl... Larry,
The only "sure fire" way to prevent a subclass from using Shadow on a
method is to prevent the sub class in the first place via the NotInheritable
keyword.
Considering one of the main reasons for Shadows is to prevent changes in
new versions of base classes from breaking existing subclasses, I think not
having an attribute is more of a good thing then a bad thing. Otherwise
class libraries could release new versions, that had such an attribute and
suddenly break existing code!
What you can do in your code is assign your object to a variable of your
base type, then call you method, assuming the method is not overridable,
you are guaranteed that your version will be called and not the Shadowed
version.
Hope this helps
Jay
"Larry Woods" <la***@lwoods.c om> wrote in message
news:u5******** ******@TK2MSFTN GP10.phx.gbl... I have a method in my base class that I want ALL derived classes to use.
But, I find that I can create a "Shadow" method in my derived class that
"overrides" the method in my base class. Can't figure out what
attribute to put on the base class method to prevent this.
TIA,
Larry Woods
Larry,
Its a matter of perspective. Looks like Shadow is a "feature" I could do without. Seems to pretty much
eliminates the possibility for guaranteeing the encapsulation of code in a
base class, right?
Wrong! :-|
The way I view it guarantees the encapsulation of code in both the base &
the derived classes! Calling the method on a variable of the derived class
will call the code that is encapsulated in the derived class, calling the
method on a variable of the base class (with a derived object) will call the
code that is encapsulated in the base class!
In other words every place you need to ensure that you are calling the base
version use a base variable! Which is then dependant of the actual type of
object you are dealing with!
For example:
Public Class Base
Public Sub ImportantMethod ()
End Class
Public Class Derived : Inherits Base
Public Shadows Sub ImporantMethod( )
End Class
Dim anObject As Base = New Derived
anObject.Import antMethod()
In the above Base.ImportantM ethod is called guaranteed! Granted it sounds
like you are using:
Dim anObject As Derived = New Derived
anObject.Import antMethod()
Which ensures that the Derived.Importa ntMethod is called, which I hope you
realize is equally important!!!! Especially when I defined
Derived.Importa ntMethod in version 1 of my project, then
Base.ImportantM ethod got defined in version 2 of my project, and changing
Derived.Importa ntMethod will not be covered by your financial backers even
with Refactoring (http://www.refactoring.com).
I get the impression you see Derived.Importa ntMethod as a clever ploy your
junior programmers can use to circumnavigate you base class design. This is
where code reviews are useful, using automated tools if possible, one of the
many Code Critics available, would identify it and you can deal with it at
that level, unless this instance falls into the versioning issue in which
case you can keep the Shadows.
Of course in your code review, you could just open the project & do a find
in files for "Shadows" instead of purchasing a Code Critic, however a Code
Critic can ensure other standards are adhered to.
Hope this helps
Jay
"Larry Woods" <la***@lwoods.c om> wrote in message
news:en******** ******@TK2MSFTN GP11.phx.gbl... Thanks, Jay.
Looks like Shadow is a "feature" I could do without. Seems to pretty much
eliminates the possibility for guaranteeing the encapsulation of code in a
base class, right?
Larry
"Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in message
news:e7******** ******@TK2MSFTN GP11.phx.gbl... Larry,
The only "sure fire" way to prevent a subclass from using Shadow on a
method is to prevent the sub class in the first place via the NotInheritable
keyword.
Considering one of the main reasons for Shadows is to prevent changes in
new versions of base classes from breaking existing subclasses, I think not
having an attribute is more of a good thing then a bad thing. Otherwise
class libraries could release new versions, that had such an attribute
and suddenly break existing code!
What you can do in your code is assign your object to a variable of your
base type, then call you method, assuming the method is not overridable,
you are guaranteed that your version will be called and not the Shadowed
version.
Hope this helps
Jay
"Larry Woods" <la***@lwoods.c om> wrote in message
news:u5******** ******@TK2MSFTN GP10.phx.gbl... I have a method in my base class that I want ALL derived classes to
use. But, I find that I can create a "Shadow" method in my derived class
that "overrides" the method in my base class. Can't figure out what
attribute to put on the base class method to prevent this.
TIA,
Larry Woods
Doh! In other words every place you need to ensure that you are calling the
base version use a base variable! Which is then dependant of the actual type of
object you are dealing with!
Should read "Which is then independent of the actual type of object you are
dealing with"
Jay
"Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in message
news:uP******** ******@TK2MSFTN GP09.phx.gbl... Larry,
Its a matter of perspective.
Looks like Shadow is a "feature" I could do without. Seems to pretty
much eliminates the possibility for guaranteeing the encapsulation of code in
a base class, right? Wrong! :-|
The way I view it guarantees the encapsulation of code in both the base &
the derived classes! Calling the method on a variable of the derived class
will call the code that is encapsulated in the derived class, calling the
method on a variable of the base class (with a derived object) will call
the code that is encapsulated in the base class!
In other words every place you need to ensure that you are calling the
base version use a base variable! Which is then dependant of the actual type of
object you are dealing with!
For example:
Public Class Base
Public Sub ImportantMethod ()
End Class
Public Class Derived : Inherits Base
Public Shadows Sub ImporantMethod( )
End Class
Dim anObject As Base = New Derived
anObject.Import antMethod()
In the above Base.ImportantM ethod is called guaranteed! Granted it sounds
like you are using:
Dim anObject As Derived = New Derived
anObject.Import antMethod()
Which ensures that the Derived.Importa ntMethod is called, which I hope you
realize is equally important!!!! Especially when I defined
Derived.Importa ntMethod in version 1 of my project, then
Base.ImportantM ethod got defined in version 2 of my project, and changing
Derived.Importa ntMethod will not be covered by your financial backers even
with Refactoring (http://www.refactoring.com).
I get the impression you see Derived.Importa ntMethod as a clever ploy your
junior programmers can use to circumnavigate you base class design. This
is where code reviews are useful, using automated tools if possible, one of
the many Code Critics available, would identify it and you can deal with it at
that level, unless this instance falls into the versioning issue in which
case you can keep the Shadows.
Of course in your code review, you could just open the project & do a find
in files for "Shadows" instead of purchasing a Code Critic, however a Code
Critic can ensure other standards are adhered to.
Hope this helps
Jay
"Larry Woods" <la***@lwoods.c om> wrote in message
news:en******** ******@TK2MSFTN GP11.phx.gbl... Thanks, Jay.
Looks like Shadow is a "feature" I could do without. Seems to pretty
much eliminates the possibility for guaranteeing the encapsulation of code in
a base class, right?
Larry
"Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in
message news:e7******** ******@TK2MSFTN GP11.phx.gbl... Larry,
The only "sure fire" way to prevent a subclass from using Shadow on a
method is to prevent the sub class in the first place via the NotInheritable
keyword.
Considering one of the main reasons for Shadows is to prevent changes
in new versions of base classes from breaking existing subclasses, I think
not having an attribute is more of a good thing then a bad thing.
Otherwise class libraries could release new versions, that had such an attribute
and suddenly break existing code!
What you can do in your code is assign your object to a variable of
your base type, then call you method, assuming the method is not
overridable, you are guaranteed that your version will be called and not the Shadowed
version.
Hope this helps
Jay
"Larry Woods" <la***@lwoods.c om> wrote in message
news:u5******** ******@TK2MSFTN GP10.phx.gbl...
> I have a method in my base class that I want ALL derived classes to
use. > But, I find that I can create a "Shadow" method in my derived class that > "overrides" the method in my base class. Can't figure out what
attribute to
> put on the base class method to prevent this.
>
> TIA,
>
> Larry Woods
>
>
Hi Larry,
I think no one can force the derived classes to call the base class's
method. If you let someone derive form you, they can change their
interface. Anyone deriving from them will indeed inherit their behavior.
The person writing the derived class's code can decide which method to
call. They are writing the code, after all.
If you are really concerned about people deriving from the class, you
should make it NonInheritable,
What is the senario? Maybe there is a better solution.
Regards,
Peter Huang
Microsoft Online Partner Support
Get Secure! www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
O.K., Jay.
So how do I GUARANTEE that my base methods are ALWAYS used by the derived
classes? My example is a pricing algorithm that is implemented through a
method in the base. Regardless of the derived class I want to be assured
that the author of the derived class CANNOT override the pricing method in
the base.
How do I do this?
TIA,
Larry
"Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in message
news:OS******** *****@TK2MSFTNG P11.phx.gbl... Doh! In other words every place you need to ensure that you are calling the base version use a base variable! Which is then dependant of the actual type
of object you are dealing with!
Should read "Which is then independent of the actual type of object you
are dealing with"
Jay
"Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in message
news:uP******** ******@TK2MSFTN GP09.phx.gbl... Larry,
Its a matter of perspective.
Looks like Shadow is a "feature" I could do without. Seems to pretty much eliminates the possibility for guaranteeing the encapsulation of code
in a base class, right? Wrong! :-|
The way I view it guarantees the encapsulation of code in both the base
& the derived classes! Calling the method on a variable of the derived
class will call the code that is encapsulated in the derived class, calling
the method on a variable of the base class (with a derived object) will call
the code that is encapsulated in the base class!
In other words every place you need to ensure that you are calling the
base version use a base variable! Which is then dependant of the actual type
of object you are dealing with!
For example:
Public Class Base
Public Sub ImportantMethod ()
End Class
Public Class Derived : Inherits Base
Public Shadows Sub ImporantMethod( )
End Class
Dim anObject As Base = New Derived
anObject.Import antMethod()
In the above Base.ImportantM ethod is called guaranteed! Granted it
sounds like you are using:
Dim anObject As Derived = New Derived
anObject.Import antMethod()
Which ensures that the Derived.Importa ntMethod is called, which I hope
you realize is equally important!!!! Especially when I defined
Derived.Importa ntMethod in version 1 of my project, then
Base.ImportantM ethod got defined in version 2 of my project, and
changing Derived.Importa ntMethod will not be covered by your financial backers
even with Refactoring (http://www.refactoring.com).
I get the impression you see Derived.Importa ntMethod as a clever ploy
your junior programmers can use to circumnavigate you base class design. This
is where code reviews are useful, using automated tools if possible, one of
the many Code Critics available, would identify it and you can deal with it
at that level, unless this instance falls into the versioning issue in
which case you can keep the Shadows.
Of course in your code review, you could just open the project & do a
find in files for "Shadows" instead of purchasing a Code Critic, however a
Code Critic can ensure other standards are adhered to.
Hope this helps
Jay
"Larry Woods" <la***@lwoods.c om> wrote in message
news:en******** ******@TK2MSFTN GP11.phx.gbl... Thanks, Jay.
Looks like Shadow is a "feature" I could do without. Seems to pretty much eliminates the possibility for guaranteeing the encapsulation of code
in a base class, right?
Larry
"Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in message news:e7******** ******@TK2MSFTN GP11.phx.gbl...
> Larry,
> The only "sure fire" way to prevent a subclass from using Shadow on
a method
> is to prevent the sub class in the first place via the
NotInheritable > keyword.
>
> Considering one of the main reasons for Shadows is to prevent
changes in new
> versions of base classes from breaking existing subclasses, I think not > having an attribute is more of a good thing then a bad thing. Otherwise > class libraries could release new versions, that had such an
attribute and > suddenly break existing code!
>
> What you can do in your code is assign your object to a variable of your > base type, then call you method, assuming the method is not overridable, you
> are guaranteed that your version will be called and not the Shadowed
> version.
>
> Hope this helps
> Jay
>
> "Larry Woods" <la***@lwoods.c om> wrote in message
> news:u5******** ******@TK2MSFTN GP10.phx.gbl...
> > I have a method in my base class that I want ALL derived classes
to use. > > But, I find that I can create a "Shadow" method in my derived
class that > > "overrides" the method in my base class. Can't figure out what
attribute
> to
> > put on the base class method to prevent this.
> >
> > TIA,
> >
> > Larry Woods
> >
> >
>
>
I agree, Peter.
Please see my response to Jay.
TIA,
Larry
"Peter Huang" <v-******@online.m icrosoft.com> wrote in message
news:yh******** ******@cpmsftng xa07.phx.gbl... Hi Larry,
I think no one can force the derived classes to call the base class's
method. If you let someone derive form you, they can change their
interface. Anyone deriving from them will indeed inherit their behavior.
The person writing the derived class's code can decide which method to
call. They are writing the code, after all.
If you are really concerned about people deriving from the class, you
should make it NonInheritable,
What is the senario? Maybe there is a better solution.
Regards,
Peter Huang
Microsoft Online Partner Support
Get Secure! www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
Larry, So how do I GUARANTEE that my base methods are ALWAYS used by the derived
classes?
I'm Sorry. Did you read any of what Peter or I said? Peter and I both told
you to Guarantee it you use NotInheritable!
Something like:
Public NotInheritable Class PricingAlgorith m
Public Function Calculate(input As Decimal) As Decimal
End Function
End Class
If NotInheritable is not an option there is NO Guarantee.
I then attempted to explain why there is No Guarantee.
Hope this helps
Jay
"Larry Woods" <la***@lwoods.c om> wrote in message
news:uL******** ******@TK2MSFTN GP11.phx.gbl... O.K., Jay.
So how do I GUARANTEE that my base methods are ALWAYS used by the derived
classes? My example is a pricing algorithm that is implemented through a
method in the base. Regardless of the derived class I want to be assured
that the author of the derived class CANNOT override the pricing method in
the base.
How do I do this?
TIA,
Larry
"Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in message
news:OS******** *****@TK2MSFTNG P11.phx.gbl... Doh! In other words every place you need to ensure that you are calling the base version use a base variable! Which is then dependant of the actual
type of object you are dealing with!
Should read "Which is then independent of the actual type of object you
are dealing with"
Jay
"Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in
message news:uP******** ******@TK2MSFTN GP09.phx.gbl... Larry,
Its a matter of perspective.
> Looks like Shadow is a "feature" I could do without. Seems to
pretty much > eliminates the possibility for guaranteeing the encapsulation of
code in a > base class, right?
Wrong! :-|
The way I view it guarantees the encapsulation of code in both the
base & the derived classes! Calling the method on a variable of the derived class will call the code that is encapsulated in the derived class, calling the method on a variable of the base class (with a derived object) will
call the code that is encapsulated in the base class!
In other words every place you need to ensure that you are calling the base version use a base variable! Which is then dependant of the actual
type of object you are dealing with!
For example:
Public Class Base
Public Sub ImportantMethod ()
End Class
Public Class Derived : Inherits Base
Public Shadows Sub ImporantMethod( )
End Class
Dim anObject As Base = New Derived
anObject.Import antMethod()
In the above Base.ImportantM ethod is called guaranteed! Granted it sounds like you are using:
Dim anObject As Derived = New Derived
anObject.Import antMethod()
Which ensures that the Derived.Importa ntMethod is called, which I hope you realize is equally important!!!! Especially when I defined
Derived.Importa ntMethod in version 1 of my project, then
Base.ImportantM ethod got defined in version 2 of my project, and changing Derived.Importa ntMethod will not be covered by your financial backers even with Refactoring (http://www.refactoring.com).
I get the impression you see Derived.Importa ntMethod as a clever ploy your junior programmers can use to circumnavigate you base class design.
This is where code reviews are useful, using automated tools if possible, one
of the many Code Critics available, would identify it and you can deal with
it at that level, unless this instance falls into the versioning issue in which case you can keep the Shadows.
Of course in your code review, you could just open the project & do a find in files for "Shadows" instead of purchasing a Code Critic, however a Code Critic can ensure other standards are adhered to.
Hope this helps
Jay
"Larry Woods" <la***@lwoods.c om> wrote in message
news:en******** ******@TK2MSFTN GP11.phx.gbl...
> Thanks, Jay.
>
> Looks like Shadow is a "feature" I could do without. Seems to
pretty much > eliminates the possibility for guaranteeing the encapsulation of
code in a > base class, right?
>
> Larry
>
> "Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in message > news:e7******** ******@TK2MSFTN GP11.phx.gbl...
> > Larry,
> > The only "sure fire" way to prevent a subclass from using Shadow
on a > method
> > is to prevent the sub class in the first place via the NotInheritable > > keyword.
> >
> > Considering one of the main reasons for Shadows is to prevent changes in > new
> > versions of base classes from breaking existing subclasses, I
think not > > having an attribute is more of a good thing then a bad thing.
Otherwise > > class libraries could release new versions, that had such an attribute and
> > suddenly break existing code!
> >
> > What you can do in your code is assign your object to a variable
of your > > base type, then call you method, assuming the method is not
overridable, > you
> > are guaranteed that your version will be called and not the
Shadowed > > version.
> >
> > Hope this helps
> > Jay
> >
> > "Larry Woods" <la***@lwoods.c om> wrote in message
> > news:u5******** ******@TK2MSFTN GP10.phx.gbl...
> > > I have a method in my base class that I want ALL derived classes
to use.
> > > But, I find that I can create a "Shadow" method in my derived class that
> > > "overrides" the method in my base class. Can't figure out what
> attribute
> > to
> > > put on the base class method to prevent this.
> > >
> > > TIA,
> > >
> > > Larry Woods
> > >
> > >
> >
> >
>
>
Hi Larry,
According to my last post, since the based class can be inherited, then it
is reasonable for the programmer to write his own method with the same name
with in base class.
I think this is be design.
Regards,
Peter Huang
Microsoft Online Partner Support
Get Secure! www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: tertius |
last post by:
Is there a better way to append certain chars in a string with a
backslash that the example below?
chr = "#$%^&_{}" # special chars to look out for
str = "123 45^ & 00 0_" # string to convert
n = "" # init new string
for i in str:
if i in chr: # if special character in str
n+='\\' # append it with a backslash
n+=i
|
by: Istvan Albert |
last post by:
Paul McGuire wrote:
> Please reconsider the "def f() :" construct. Instead of
> invoking a special punctuation character, it uses context and placement,
> with familiar old 's, to infuse the declaration of a function with special
> characteristics. If this causes def lines to run longer than one line,
> perhaps the same rule that allows an unmatched "(" to carry over multiple
> lines without requiring "\" continuation markers could be...
|
by: BJörn Lindqvist |
last post by:
I think it would be cool if you could refer to instance variables
without prefixing with "self." I know noone else thinks like me so
Python will never be changed, but maybe you can already do it with
Python today?
..import sys
..
..def magic():
.. s = ""
.. for var in sys._getframe(1).f_locals.__dict__:
|
by: James A. Donald |
last post by:
I am contemplating getting into Python, which is used by engineers I
admire - google and Bram Cohen, but was horrified to read
"no variable or argument declarations are necessary."
Surely that means that if I misspell a variable name, my program will
mysteriously fail to work with no error message.
If you don't declare variables, you can inadvertently re-use an
variable used in an enclosing context when you don't intend to, or
|
by: Klaus Löffelmann |
last post by:
Hi,
maybe it's already too late, but what is the deal with overwriting
Object.Equals.
I have to use "overrides overloads" to really overwrite the correct
'version' of equals, even if a single overrides should uniquely point to the
right signature. A single 'overrides' isn't possible, though. But it is
possible to only overload Equals with exactly the same signature the base
method has. So, would that then be a shadowing without warning?
| | |
by: Dave Taylor |
last post by:
I'm trying to derive a class from a typed DataSet to add some methods to one
of the DataTables. I would like to keep the names the same in the derived
class as in the base class, so I have used "Shadows" to hide the base class
members. However, this does not seem to work. Any pointers as to what I'm
doing wrong here? (I've attached the basics of the code below). Thanks
Dave Taylor
|
by: JohnR |
last post by:
In it's simplest form, assume that I have created a usercontrol,
WSToolBarButton that contains a button. I would like to eventually create
copies of WSToolBarButton dynamically at run time based on some
initialization information obtained elsewhere. Basically, I'm going to
create my own dynamic toolbar where the toolbarbuttons can change. I'm not
using the VB toolbar because of limitations in changing things like
backcolor (I can't get...
|
by: utab |
last post by:
Dear all,
Is there a clear distinction how to decide which functions to be
members of a class and which not
How is your attitude (Your general way from your experiences ...)
"If the function changes the state of the object, it ought to be a
member of that object." Reference Accelerated C++, A. Koenig, page 159.
|
by: Jeremy J Starcher |
last post by:
While reading c.l.j, I've noticed that some people prefer and indeed even
recommend the use of "window.alert()" over "alert()".
I can't find any technical reason to make this distinction, and seems to
have a (tiny) amount overhead since window itself points to the global
object, hence, a circular reference.
(From everything I am reading, window is just a REFERENCE back to the
global object, as opposed to a separate object.)
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look !
Part I. Meaning of...
|
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 synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
| | |
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...
|
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...
|
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,...
|
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...
|
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.
| | |
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...
| |
