Except for legacy or non-.NET applications, is there any reason to use VC++
anymore? It seems that for .NET applications, there would be no reason to
choose C++ over C# since C# is faster to develop with (i.e. no header files,
objects are easier to create and use, C# language is native to .NET)
I'm sure this question will stir some emotions :-)
--
Greg McPherran www.McPherran.com
Nov 29 '05
37  2159 
I've heard VS C++.NET can run from 6-10 times FASTER than VS C#.NET. That's
a pretty good selling point right there... : )
[==P==]
"Herby" <pr********@gma il.com> wrote in message
news:11******** **************@ g49g2000cwa.goo glegroups.com.. . We have chosen C++\CLI as our current source code base is in C++ and
provides a clear migration path.
Its also a benefit for us to be able to use mixed mode using both the
un-managed and managed heap in the same application/function.
You could almost think of the syntax extensions almost independent of
.NET. Just can now work with a garbage collector etc.
Sure, for those who believe this nonsense. Those who ran some benchmarks
know that there is almost no difference, for some specific cases C++/CLI is
a bit faster and in other cases C# is a bit faster. This is quite normal if
you know that both front-end compilers emit MSIL and the bulk of the
optimizations are done at JIT compile time. Sure the C++ compiler can spend
some extra time to optimize MSIL, while the C# compiler is more time
constrained, but in reality there is very little that can be done at the
MSIL level. Note also that a great deal of the code that gets executed in a
real world application comes from the FCL which is written in C#.
Believe me, performance is not C++/CLI's selling point.
Willy.
"Peter Oliphant" <po*******@Roun dTripInc.com> wrote in message
news:en******** ******@TK2MSFTN GP15.phx.gbl... I've heard VS C++.NET can run from 6-10 times FASTER than VS C#.NET.
That's a pretty good selling point right there... : )
[==P==]
"Herby" <pr********@gma il.com> wrote in message
news:11******** **************@ g49g2000cwa.goo glegroups.com.. . We have chosen C++\CLI as our current source code base is in C++ and
provides a clear migration path.
Its also a benefit for us to be able to use mixed mode using both the
un-managed and managed heap in the same application/function.
You could almost think of the syntax extensions almost independent of
.NET. Just can now work with a garbage collector etc.
I never did any benchmarks, so I was basing my statement on other reports.
Thus I believe your findings more than what I've read (even though,
ironically, all I've done is read what you've said in saying this...lol). So
speed is not a selling point.
Still, I prefer to use C++ over C#, probably just because I prefer (am more
familiar with) the syntax. And, I'm afraid of seeing this pop up one day on
the MS website:
"MS has deprecated C++ in favor of C#". <shiver>
[==P==]
"Willy Denoyette [MVP]" <wi************ *@telenet.be> wrote in message
news:%2******** **********@TK2M SFTNGP10.phx.gb l... Sure, for those who believe this nonsense. Those who ran some benchmarks
know that there is almost no difference, for some specific cases C++/CLI
is a bit faster and in other cases C# is a bit faster. This is quite
normal if you know that both front-end compilers emit MSIL and the bulk of
the optimizations are done at JIT compile time. Sure the C++ compiler can
spend some extra time to optimize MSIL, while the C# compiler is more time
constrained, but in reality there is very little that can be done at the
MSIL level. Note also that a great deal of the code that gets executed in
a real world application comes from the FCL which is written in C#.
Believe me, performance is not C++/CLI's selling point.
Willy.
"Peter Oliphant" <po*******@Roun dTripInc.com> wrote in message
news:en******** ******@TK2MSFTN GP15.phx.gbl... I've heard VS C++.NET can run from 6-10 times FASTER than VS C#.NET.
That's a pretty good selling point right there... : )
[==P==]
"Herby" <pr********@gma il.com> wrote in message
news:11******** **************@ g49g2000cwa.goo glegroups.com.. . We have chosen C++\CLI as our current source code base is in C++ and
provides a clear migration path.
Its also a benefit for us to be able to use mixed mode using both the
un-managed and managed heap in the same application/function.
You could almost think of the syntax extensions almost independent of
.NET. Just can now work with a garbage collector etc.
"Peter Oliphant" <po*******@Roun dTripInc.com> wrote in message
news:ul******** *******@tk2msft ngp13.phx.gbl.. . I never did any benchmarks, so I was basing my statement on other reports.
Thus I believe your findings more than what I've read (even though,
ironically, all I've done is read what you've said in saying this...lol).
So speed is not a selling point.
Still, I prefer to use C++ over C#, probably just because I prefer (am
more familiar with) the syntax. And, I'm afraid of seeing this pop up one
day on the MS website:
"MS has deprecated C++ in favor of C#". <shiver>
C++ != C++/CLI remember!
What's possible is that you may see "MS has deprecated C++/CLI in favor of
C#", but they would never deprecate the language (native C++) they use to
build >95% of their products.
Willy.
Here's what I'm getting at. I use to program in C++ before managed stuff
came into play (gc). So, when managed stuff did come into play, I had to
convert my stuff to it. Then CLI came into play. Now I'm converting my stuff
to CLI since gc has been deprecated.
Short of only using 'vanilla' C++, can I ever write code I'm sure will still
be valid 'forever'? That is, code that can be re-used in future projects,
say, 2+ years from now? How can one build a library of tools if the syntax
keeps changing? Hence, I'm even worried about :
"MS has deprecated C++/CLI in favor of C#". <shiver>
Has CLI been made to be 'here to stay", or can we expect some VS.NET 2007
upgrade to possibly deprecate CLI and expect us to learn yet another new
syntax? Like I've mentioned before, one of the purposes of languages like
C++ is the concept it will be re-usable in the future. This constantly
changing the syntax violates that contract.
IMHO, a new version of a product should always be 100% backwards comaptible
IF it's going to be called an UPGRADE. CLI is not backwards comaptible with
'gc', thus requiring conversion time that shouldn't be necessary for an
upgrade, but in this case is absolutely required. Hence, VS 2005 is not an
upgrade to 2003, IMHO, but a 'new' language.
That being said, I really enjoy this new syntax, but wish I hadn't learned
and programmed using "gc" syntax so much. And having done that, I'm worried
a bit about investing time in CLI, since it could be deprecated in a few
years too.
Do we have ANY guarantee along these lines, even in terms of limited-time
(i.e., MS warrants that CLI will NOT be deprecated for X number of years)?
[==P==]
"Willy Denoyette [MVP]" <wi************ *@telenet.be> wrote in message
news:Os******** ********@TK2MSF TNGP11.phx.gbl. ..
"Peter Oliphant" <po*******@Roun dTripInc.com> wrote in message
news:ul******** *******@tk2msft ngp13.phx.gbl.. .I never did any benchmarks, so I was basing my statement on other reports.
Thus I believe your findings more than what I've read (even though,
ironically, all I've done is read what you've said in saying this...lol).
So speed is not a selling point.
Still, I prefer to use C++ over C#, probably just because I prefer (am
more familiar with) the syntax. And, I'm afraid of seeing this pop up one
day on the MS website:
"MS has deprecated C++ in favor of C#". <shiver>
C++ != C++/CLI remember!
What's possible is that you may see "MS has deprecated C++/CLI in favor of
C#", but they would never deprecate the language (native C++) they use to
build >95% of their products.
Willy.
"Peter Oliphant" <po*******@Roun dTripInc.com> skrev i meddelandet
news:ui******** ********@TK2MSF TNGP11.phx.gbl. .. Here's what I'm getting at. I use to program in C++ before managed
stuff came into play (gc). So, when managed stuff did come into
play, I had to convert my stuff to it. Then CLI came into play. Now
I'm converting my stuff to CLI since gc has been deprecated.
Short of only using 'vanilla' C++, can I ever write code I'm sure
will still be valid 'forever'? That is, code that can be re-used in
future projects, say, 2+ years from now? How can one build a library
of tools if the syntax keeps changing? Hence, I'm even worried
about:
"MS has deprecated C++/CLI in favor of C#". <shiver>
Has CLI been made to be 'here to stay", or can we expect some VS.NET
2007 upgrade to possibly deprecate CLI and expect us to learn yet
another new syntax? Like I've mentioned before, one of the purposes
of languages like C++ is the concept it will be re-usable in the
future. This constantly changing the syntax violates that contract.
IMHO, a new version of a product should always be 100% backwards
comaptible IF it's going to be called an UPGRADE. CLI is not
backwards comaptible with 'gc', thus requiring conversion time that
shouldn't be necessary for an upgrade, but in this case is
absolutely required. Hence, VS 2005 is not an upgrade to 2003, IMHO,
but a 'new' language.
That being said, I really enjoy this new syntax, but wish I hadn't
learned and programmed using "gc" syntax so much. And having done
that, I'm worried a bit about investing time in CLI, since it could
be deprecated in a few years too.
Do we have ANY guarantee along these lines, even in terms of
limited-time (i.e., MS warrants that CLI will NOT be deprecated for
X number of years)?
Noooo!
You will never, ever get any guarantees at all.
I was around when MS introduced Windows 1.0. Several years ago... :-)
At the time, the promise was "learn this new Windows API, and you will
never have to learn another interface again".
Yeah, right!
Bo Persson
"Peter Oliphant" <po*******@Roun dTripInc.com> wrote in message
news:ui******** ********@TK2MSF TNGP11.phx.gbl. .. Here's what I'm getting at. I use to program in C++ before managed stuff
came into play (gc). So, when managed stuff did come into play, I had to
convert my stuff to it.
Why? Is someone holding a gun to your head?
In our development environment, we start from the premise that "what isn't
broken shouldn't be fixed". Perhaps there was a compelling reason on your
case, but I wouldn't be seduced into "upgrading" your source code simply
because the features become available.
Then CLI came into play. Now I'm converting my stuff to CLI since gc has
been deprecated.
Short of only using 'vanilla' C++, can I ever write code I'm sure will
still be valid 'forever'? That is, code that can be re-used in future
projects, say, 2+ years from now? How can one build a library of tools if
the syntax keeps changing? Hence, I'm even worried about:
"MS has deprecated C++/CLI in favor of C#". <shiver>
C++/CLI offers capabilities and a blending of the managed and native worlds
that cannot be duplicated with C#. I can assure you it is here for the long
term.
Has CLI been made to be 'here to stay", or can we expect some VS.NET 2007
upgrade to possibly deprecate CLI and expect us to learn yet another new
syntax? Like I've mentioned before, one of the purposes of languages like
C++ is the concept it will be re-usable in the future. This constantly
changing the syntax violates that contract.
I disagree. Language extensions are never a contract, and that is exactly
what the old syntax represented. The old syntax is still supported, so you
have lots of time to adapt to the new "language extensions". Obviously, it
is not in the vendor's interest to keep modifying the language extensions
with each new version. But in this case, the syntax has been cleaned up, and
there is a clearer distinction between native pointers and reference
pointers.
IMHO, a new version of a product should always be 100% backwards
comaptible
Egad.... then I daresay you haven't had much experience putting out a
product that is widely used. There is a natural conflict between maintaining
backwards-compatibility and jettisoning out-dated and dangerous features and
coding styles. The former doesn't always win.
Indeed, even your favourite language C doesn't support the early versions of
the language when it was first developed by Bell Labs. Remember when int's
and pointers could be used pretty much interchangeably ? Do you really want
to continue to support that?
IF it's going to be called an UPGRADE. CLI is not backwards comaptible
with 'gc', thus requiring conversion time that shouldn't be necessary for
an upgrade, but in this case is absolutely required. Hence, VS 2005 is not
an upgrade to 2003, IMHO, but a 'new' language.
That being said, I really enjoy this new syntax, but wish I hadn't learned
and programmed using "gc" syntax so much.
I think that is the real burn you are feeling. I managed to skip the "gc"
syntax... it was ugly, and Microsoft indicated this was going to be
revamped.
And having done that, I'm worried a bit about investing time in CLI, since
it could be deprecated in a few years too.
Again, don't worry. This is going to be around for the long term. Expect
improvements, bug fixes, and so on, but nothing as drastic as the recent
"upgrade".
Do we have ANY guarantee along these lines, even in terms of limited-time
(i.e., MS warrants that CLI will NOT be deprecated for X number of years)?
I wouldn't expect a guarantee from Microsoft. But they do listen to their
developers, and they do read this newsgroup, so your posting will be noted.
Brian (and I don't represent Microsoft :-)
>>Why? Is someone holding a gun to your head?
This is how it went. I was using 2003 just fine. 2005 comes out, so our
company upgrades. We want the newest stuff because UPGRADES typically fix
any old problems and bugs.
I then took the 'old' source and decided to now use 2005. What's this? It
wants to convert my 2003 source to 2005 format, and tells me there is no way
to reverse? Ok, that's fine, no problem. Then, guess what? It doesn't
compile because its not backwards compatible...
Yes, I still have backups of the 2003 version, and I could use them. BUT -
MS has announced that 'gc' has been deprecated. So, if I continue to use
2003 MS has aggresively announced they won't support my code in the near
future...
So, YES, there IS a gun being held to my head in this matter... : ) The old syntax is still supported...
.... but has been deprecated by MS, and 'deprecated' mean 'will not be
supported in the near future'. So if I choose not to learn the syntax of
2005 MS says I'm on my own...
Egad.... then I daresay you haven't had much experience putting out a
product that is widely used. There is a natural conflict between
maintaining
Yeah, only 20+ published computer games, some of which have sold
platinum...lol I've been designing and programming now for 36 years. One
of my computer game projects took 5 years (that should have taken 2 years)
because CPU's kept upgrading:
286 -> 386 -> 486 -> Pentium
Now this can happen becuase languages change. That's not good...
Again, don't worry. This is going to be around for the long term.
Didn't MS say this about 'gc' syntax too? : )
[==P==]
PS - Like I said, I do love the new syntax, but I now have at least three
different syntax's running around in my head and like 50,000 lines of
library tool code that has seen all three versions. Had they just skipped
'gc' and gone directly to 'CLI' I'd have been mch happier. But hey, I like
product testing (and paying $1000's for the privilege for upgrades) so MS
can get it right... LOL
Seriously, I do think MS is doing a good job here with CLI and the way all
of the languages (VB, C++, J#, and C#) use a common basis. Just they could
have been more forthcoming about how 2003 won't compile under 2005 without
changes...
"Brian Muth" <bm***@mvps.org > wrote in message
news:eJ******** *******@tk2msft ngp13.phx.gbl.. .
"Peter Oliphant" <po*******@Roun dTripInc.com> wrote in message
news:ui******** ********@TK2MSF TNGP11.phx.gbl. .. Here's what I'm getting at. I use to program in C++ before managed stuff
came into play (gc). So, when managed stuff did come into play, I had to
convert my stuff to it.
Why? Is someone holding a gun to your head?
In our development environment, we start from the premise that "what isn't
broken shouldn't be fixed". Perhaps there was a compelling reason on your
case, but I wouldn't be seduced into "upgrading" your source code simply
because the features become available.
Then CLI came into play. Now I'm converting my stuff to CLI since gc has
been deprecated.
Short of only using 'vanilla' C++, can I ever write code I'm sure will
still be valid 'forever'? That is, code that can be re-used in future
projects, say, 2+ years from now? How can one build a library of tools if
the syntax keeps changing? Hence, I'm even worried about:
"MS has deprecated C++/CLI in favor of C#". <shiver>
C++/CLI offers capabilities and a blending of the managed and native
worlds that cannot be duplicated with C#. I can assure you it is here for
the long term.
Has CLI been made to be 'here to stay", or can we expect some VS.NET 2007
upgrade to possibly deprecate CLI and expect us to learn yet another new
syntax? Like I've mentioned before, one of the purposes of languages like
C++ is the concept it will be re-usable in the future. This constantly
changing the syntax violates that contract.
I disagree. Language extensions are never a contract, and that is exactly
what the old syntax represented. The old syntax is still supported, so you
have lots of time to adapt to the new "language extensions". Obviously, it
is not in the vendor's interest to keep modifying the language extensions
with each new version. But in this case, the syntax has been cleaned up,
and there is a clearer distinction between native pointers and reference
pointers.
IMHO, a new version of a product should always be 100% backwards
comaptible
Egad.... then I daresay you haven't had much experience putting out a
product that is widely used. There is a natural conflict between
maintaining backwards-compatibility and jettisoning out-dated and
dangerous features and coding styles. The former doesn't always win.
Indeed, even your favourite language C doesn't support the early versions
of the language when it was first developed by Bell Labs. Remember when
int's and pointers could be used pretty much interchangeably ? Do you
really want to continue to support that?
IF it's going to be called an UPGRADE. CLI is not backwards comaptible
with 'gc', thus requiring conversion time that shouldn't be necessary for
an upgrade, but in this case is absolutely required. Hence, VS 2005 is
not an upgrade to 2003, IMHO, but a 'new' language.
That being said, I really enjoy this new syntax, but wish I hadn't
learned and programmed using "gc" syntax so much.
I think that is the real burn you are feeling. I managed to skip the "gc"
syntax... it was ugly, and Microsoft indicated this was going to be
revamped.
And having done that, I'm worried a bit about investing time in CLI,
since it could be deprecated in a few years too.
Again, don't worry. This is going to be around for the long term. Expect
improvements, bug fixes, and so on, but nothing as drastic as the recent
"upgrade".
Do we have ANY guarantee along these lines, even in terms of limited-time
(i.e., MS warrants that CLI will NOT be deprecated for X number of
years)?
I wouldn't expect a guarantee from Microsoft. But they do listen to their
developers, and they do read this newsgroup, so your posting will be
noted.
Brian (and I don't represent Microsoft :-)
> Yes, I still have backups of the 2003 version, and I could use them. BUT -
MS has announced that 'gc' has been deprecated. So, if I continue to use
2003 MS has aggresively announced they won't support my code in the near
future...
Can you support this statement with a link?
So, YES, there IS a gun being held to my head in this matter... : )
The old syntax is still supported...
... but has been deprecated by MS, and 'deprecated' mean 'will not be
supported in the near future'.
Nonsense.
RDS has been deprecated for 6 years. Yet it is still present in Microsoft
Windows 2003 Server and therefore it is still supported.
"Deprecated " does not mean "it will be not supported in the near future". It
does mean that there is no further R&D in this area. It is a strong hint
that new code should adopt the recommended replacement technology. But it
shouldn't make you panic and start tearing up your old code. In the case of
RDS, the software is sealed, so it means there will be no changes to the
software in future releases. But RDS is still around today. And I'll bet RDS
is going to appear in Windows Vista, identical to the code present in
Windows 2003 Server.
[==P==]
PS - Like I said, I do love the new syntax, but I now have at least three
different syntax's running around in my head and like 50,000 lines of
library tool code that has seen all three versions. Had they just skipped
'gc' and gone directly to 'CLI' I'd have been mch happier.
Agree whole-heartedly.
Seriously, I do think MS is doing a good job here with CLI and the way all
of the languages (VB, C++, J#, and C#) use a common basis. Just they could
have been more forthcoming about how 2003 won't compile under 2005 without
changes...
I have to admit I don't feel the same compulsion to recompile my code under
the latest compiler. I have lots of code that compiles just fine under VC
6.0, and I really don't care if MS stops supporting this version of the
compiler one day. My code will still compile without their support.
>> MS has announced that 'gc' has been deprecated.... Can you support this statement with a link?
Sure: http://msdn2.microsoft.com/en-us/lib...us,VS.80).aspx
Quote on this page ("This syntax" refers to C++/CLI syntax):
"This syntax replaces the previous syntax, known as Managed Extensions for
C++. Managed Extensions for C++ syntax is are still available, but as a
deprecated feature under /clr:oldSyntax compiler option."
[==P==]
"Brian Muth" <bm***@mvps.org > wrote in message
news:OR******** *******@TK2MSFT NGP14.phx.gbl.. .
Yes, I still have backups of the 2003 version, and I could use them.
BUT - MS has announced that 'gc' has been deprecated. So, if I continue
to use 2003 MS has aggresively announced they won't support my code in
the near future...
Can you support this statement with a link?
So, YES, there IS a gun being held to my head in this matter... : )
The old syntax is still supported...
... but has been deprecated by MS, and 'deprecated' mean 'will not be
supported in the near future'.
Nonsense.
RDS has been deprecated for 6 years. Yet it is still present in Microsoft
Windows 2003 Server and therefore it is still supported.
"Deprecated " does not mean "it will be not supported in the near future".
It does mean that there is no further R&D in this area. It is a strong
hint that new code should adopt the recommended replacement technology.
But it shouldn't make you panic and start tearing up your old code. In the
case of RDS, the software is sealed, so it means there will be no changes
to the software in future releases. But RDS is still around today. And
I'll bet RDS is going to appear in Windows Vista, identical to the code
present in Windows 2003 Server.
[==P==]
PS - Like I said, I do love the new syntax, but I now have at least three
different syntax's running around in my head and like 50,000 lines of
library tool code that has seen all three versions. Had they just skipped
'gc' and gone directly to 'CLI' I'd have been mch happier.
Agree whole-heartedly.
Seriously, I do think MS is doing a good job here with CLI and the way
all of the languages (VB, C++, J#, and C#) use a common basis. Just they
could have been more forthcoming about how 2003 won't compile under 2005
without changes...
I have to admit I don't feel the same compulsion to recompile my code
under the latest compiler. I have lots of code that compiles just fine
under VC 6.0, and I really don't care if MS stops supporting this version
of the compiler one day. My code will still compile without their support.
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Peter Nolan |
last post by:
Hello,
Is VC++ 6.0 available to buy anymore?
I've just been to www.msdn.microsoft.com and it doesn't look it.
Peter Nolan.
Dublin.
|
by: Anders Eriksson |
last post by:
Hello!
I don't get it! How do I use an ActiveX control in VC++ 7.1??
I'm using MFC and I have added the ActiveX control to my ToolBox and then
added it to my CFormView.
In VC++ 6.0 there was created a Wrapper Class automatically , but not
anymore.
|
by: Michael Nemtsev |
last post by:
I've seen a lot of times using return value in parentesises -
{
....
return (true);
}
What's the reason for this? Can smb explait it?
PS: they do return predefined values, not calculated like returd (I*(d/4))
--
|
by: Frederico Pissarra |
last post by:
Recently I tried to use -G5 option on CL compiler (from Visual Studio
2005)... To my surprise, there is no processor specific optimizations
anymore! Is that correct?
Is so, why?
s
Fred
|
by: Herhor |
last post by:
Hello!
I have already started C++ programming with VC++ 2005 Express Edition.
Unfortunately during debugging one of my first programs I had to
unintentionally enable some debugger configuration feature which turns
on Disassembly Window at the end of every my program (basic example below).
int main()
{
//some instructions;
| | |
by: Jason Doucette |
last post by:
I'm getting an assertion fire from a list iterator being checked
against NULL. This did not occur in VC++ 2003 (v7.1). Are there
changes that have been made to the STL between these versions that I
should know about? Any resources I should check into?
thanks,
Jason
|
by: TheFid |
last post by:
In case someone knows off the top....
I am accessing a COM-interface-exposing C# dll in VC++ 6. The C# disp
method can throw a COMException.
Do I catch a _com_error ? It's not obvious from the docs.
TIA,
Mike
|
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: 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: 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...
|
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...
| | |
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...
|
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 into image.
Globals.ThisAddIn.Application.ActiveDocument.Select();...
|
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: 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...
| |
