LongPtr

[Deanna Earley]

Since when did VBA support LongPtr??
I've just noticed it in Excel (2010) VBA (7) and it's a recognised type.

It's nowhere to be seen in the object browser and there is no associated
vbVarType constant for it.

VBA7 is not .Net based either as other Vb.Net keywords and operators
aren't supported.

[Deanna Earley]

Post by Deanna Earley
Since when did VBA support LongPtr??
I've just noticed it in Excel (2010) VBA (7) and it's a recognised type.
It's nowhere to be seen in the object browser and there is no associated
vbVarType constant for it.
VBA7 is not .Net based either as other Vb.Net keywords and operators
aren't supported.

Oh, just VBA in Excel 2010 and 2013 apparently:
http://msdn.microsoft.com/en-us/library/office/gg251378.aspx
I'd much prefer LongLong on a 32-bit system though :(

[GS]

Post by Deanna Earley

Post by Deanna Earley
Since when did VBA support LongPtr??
I've just noticed it in Excel (2010) VBA (7) and it's a recognised type.
It's nowhere to be seen in the object browser and there is no
associated
vbVarType constant for it.
VBA7 is not .Net based either as other Vb.Net keywords and
operators
aren't supported.

http://msdn.microsoft.com/en-us/library/office/gg251378.aspx
I'd much prefer LongLong on a 32-bit system though :(

Just to clarify...

LongPtr in VBA7 is supported for x64 versions of MS Office. When
running x32 it won't matter if VBA is still v7 (AFAIK)!
--
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion



---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[ralph]

Post by GS

Post by Deanna Earley

Post by Deanna Earley
Since when did VBA support LongPtr??
I've just noticed it in Excel (2010) VBA (7) and it's a recognised type.
It's nowhere to be seen in the object browser and there is no associated
vbVarType constant for it.
VBA7 is not .Net based either as other Vb.Net keywords and
operators
aren't supported.

http://msdn.microsoft.com/en-us/library/office/gg251378.aspx
I'd much prefer LongLong on a 32-bit system though :(

Just to clarify...
LongPtr in VBA7 is supported for x64 versions of MS Office. When
running x32 it won't matter if VBA is still v7 (AFAIK)!

Don't feel that particularly "clarified" the LongPtr.

I think you meant to say, one only needs to modify VBA code if it is
required to run in a 64-bit version of Office. LongPtr is available
for both 32-bit and 64-bit versions of Office using VBA7.

While it refers to an 'integer' type it should ONLY be used for
pointers and handles.

For years in previous versions of VBA and VB we have used a Long to
hold a 32-bit pointer/address, to the point that they have become
almost synonymous. Such thinking becomes a disaster when dealing with
addresses in a mixed enviroment.

Obviously using LongPtr in a VBA module/macro you plan to migrate is a
good idea. It is also a good practice to start using it in the newer
32-bit enviroment as well - a good reminder we are dealing with a
pointer/handle and NOT just a numerical datatype. (Unless of course
you plan to still support previous VBA versions. <g>)

The issue of using LongLong or Long as integer datatypes for
calculations or storage in a mixed environment is a separate but
related issue, due to scale. A LongPtr can be used mask the problem -
allowing VBA to run without disaster - but results are likely to be
surprising at best. <g>

-ralph
[* Note: Since VBA runs within the context of the Office version using
it, "environment" in this case means the version of Office being used.
Not the O/S or "system".]

[GS]

Post by ralph

Post by GS

Post by Deanna Earley

Post by Deanna Earley
Since when did VBA support LongPtr??
I've just noticed it in Excel (2010) VBA (7) and it's a recognised type.
It's nowhere to be seen in the object browser and there is no associated
vbVarType constant for it.
VBA7 is not .Net based either as other Vb.Net keywords and
operators
aren't supported.

http://msdn.microsoft.com/en-us/library/office/gg251378.aspx
I'd much prefer LongLong on a 32-bit system though :(

Just to clarify...
LongPtr in VBA7 is supported for x64 versions of MS Office. When
running x32 it won't matter if VBA is still v7 (AFAIK)!

Don't feel that particularly "clarified" the LongPtr.
I think you meant to say, one only needs to modify VBA code if it is
required to run in a 64-bit version of Office. LongPtr is available
for both 32-bit and 64-bit versions of Office using VBA7.
While it refers to an 'integer' type it should ONLY be used for
pointers and handles.
For years in previous versions of VBA and VB we have used a Long to
hold a 32-bit pointer/address, to the point that they have become
almost synonymous. Such thinking becomes a disaster when dealing with
addresses in a mixed enviroment.
Obviously using LongPtr in a VBA module/macro you plan to migrate is
a good idea. It is also a good practice to start using it in the
newer 32-bit enviroment as well - a good reminder we are dealing with
a pointer/handle and NOT just a numerical datatype. (Unless of course
you plan to still support previous VBA versions. <g>)

I pretty much agree with everything you say here. My understanding of
its usage is to use conditional declares in code for backward
compatibility when same code is used for both.

Also, I don't believe x32 office uses VBA7 as my understanding is it's
x64 only, but I may be wrong about that since I haven't yet worked with
any versions after 2007!

Post by ralph
The issue of using LongLong or Long as integer datatypes for
calculations or storage in a mixed environment is a separate but
related issue, due to scale. A LongPtr can be used mask the problem -
allowing VBA to run without disaster - but results are likely to be
surprising at best. <g>
-ralph
[* Note: Since VBA runs within the context of the Office version
using it, "environment" in this case means the version of Office
being used. Not the O/S or "system".]

--
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion



---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[ralph]

Post by GS
Also, I don't believe x32 office uses VBA7 as my understanding is it's
x64 only, but I may be wrong about that since I haven't yet worked with
any versions after 2007!

Ha.

Now that you called me on it, I'm not so sure myself. As a consultant
I've used various versions of Office on different platforms a lot
recently. I sure thought it was there, at least on some version of
Office or one of its products. But as this current box is 32-bit
Office 2007 I'm not in any position to check atm. (And too lazy to go
online and leaf through all the product documentation.)

Although basically OT, if I'm wrong - and if I know the visitors to
this newsgroup - it is only a matter of time before I get corrected.
<g>

-ralph

[GS]

Post by ralph
Although basically OT, if I'm wrong - and if I know the visitors to
this newsgroup - it is only a matter of time before I get corrected.
<g>

Ha! This holds true for all of us...
--
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion



---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[Deanna Earley]

Post by GS

Post by ralph
Although basically OT, if I'm wrong - and if I know the visitors to
this newsgroup - it is only a matter of time before I get corrected.
<g>

Ha! This holds true for all of us...

Only too happy to help :p

[Deanna Earley]

Post by GS
Also, I don't believe x32 office uses VBA7 as my understanding is it's
x64 only, but I may be wrong about that since I haven't yet worked with
any versions after 2007!

My x32 Excel 2010 (14.0.7106.5003 32-bit) is using VBA7 (7.0.1628)

[GS]

Post by Deanna Earley

Post by GS
Also, I don't believe x32 office uses VBA7 as my understanding is it's
x64 only, but I may be wrong about that since I haven't yet worked with
any versions after 2007!

My x32 Excel 2010 (14.0.7106.5003 32-bit) is using VBA7 (7.0.1628)

Thanks for confirming! I guess it's time I pull iout my install disc
and start using 2010. I've been putting it off because I was hoping
x32/x64 could coexist on the same machine. The delay persisted since
the latest version used by my clients is 2007.

Anyway, any code you write that contains elements not compatible with
VBA6 needs to be *version aware*, if it's even possible that code will
run in earlier versions.
--
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion



---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[Tony Toews]

Post by GS
LongPtr in VBA7 is supported for x64 versions of MS Office.

MS doesn't recommend running x64 Office unless you really need to.
It's my understanding that the 32bit and x64 bit versions can't
coexist which is a PITA. There's been some discussion on the quirks in
running Access in 64 bit mode. I've pretty much ignored the
discussion. <smile>

Tony

[GS]

Post by Tony Toews

Post by GS
LongPtr in VBA7 is supported for x64 versions of MS Office.

MS doesn't recommend running x64 Office unless you really need to.
It's my understanding that the 32bit and x64 bit versions can't
coexist which is a PITA. There's been some discussion on the quirks
in running Access in 64 bit mode. I've pretty much ignored the
discussion. <smile>
Tony

I have the same understanding about coexistence. My point was with
respect to using the same code for use by both versions. Note, though,
that when compiling a project it needs to be done 'natively', meaning
the project files for the x32 version won't work in x64 and vice versa!
--
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion



---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[ralph]

On Wed, 22 Jan 2014 15:03:23 -0700, Tony Toews

Post by Tony Toews

Post by GS
LongPtr in VBA7 is supported for x64 versions of MS Office.

MS doesn't recommend running x64 Office unless you really need to.
It's my understanding that the 32bit and x64 bit versions can't
coexist which is a PITA. There's been some discussion on the quirks in
running Access in 64 bit mode. I've pretty much ignored the
discussion. <smile>

I can testify that it can become an adventure.

In one shop, the resident business expert and Excel guru (also
something of a technophile) insisted on using 64-bit Office, while the
rest remained with 32-bit versions. He used a slew of
Addons/Macros/etc. It was less a disaster and more an annoyance, but
was a constant distraction. He ended up re-writing all his toys.
(Although I secretly believe he enjoyed doing it.)

But from a business point of view, his results occasionally varied
from his previous models, and from those of others. Not necessarily
dramatically, nor constantly, but just enough to always add a degree
of doubt. He was always slightly out-of-phase with the rest. Only
lasted about 6 months until he got the "bugs out", but that was still
6 months of extra distraction away from the business.

He was sharp enough to ferret out and correct any inconstancies, but I
pity the poor shop, without experts, that just blindly jumps to 64-bit
Office without fully understanding the consequences. If they do, then
at least make it universal. <g>

-ralph

[GS]

Hi Deanna,
I finally got around to installing MSO2010 and here's what I found in
VBA7 online help...


LongPtr Data Type

LongPtr (Long integer on 32-bit systems, LongLong integer on 64-bit
systems) variables are stored as signed 32-bit (4-byte) numbers ranging
in value from -2,147,483,648 to 2,147,483,647 on 32-bit systems; and
signed 64-bit (8-byte) numbers ranging in value from
-9,223,372,036,854,775,808 to 9,223,372,036,854,775,807 on 64-bit
systems.


Note
LongPtr is not a true data type because it transforms to a Long in
32-bit environments, or a LongLong in 64-bit environments. Using
LongPtr enables writing portable code that can run in both 32-bit and
64-bit environments. Use LongPtr for pointers and handles.