Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.basic.visual.misc > #1996 > unrolled thread

LongPtr

Back to article view | Back to comp.lang.basic.visual.misc

Contents

  LongPtr Deanna Earley <dee.earley@icode.co.uk> - 2014-01-22 14:22 +0000
    Re: LongPtr Deanna Earley <dee.earley@icode.co.uk> - 2014-01-22 14:25 +0000
      Re: LongPtr GS <gs@somewhere.net> - 2014-01-22 12:09 -0500
        Re: LongPtr ralph <nt_consulting@yahoo.com> - 2014-01-22 15:36 -0600
          Re: LongPtr GS <gs@somewhere.net> - 2014-01-22 16:49 -0500
            Re: LongPtr ralph <nt_consulting@yahoo.com> - 2014-01-22 16:11 -0600
              Re: LongPtr GS <gs@somewhere.net> - 2014-01-22 17:16 -0500
                Re: LongPtr Deanna Earley <dee.earley@icode.co.uk> - 2014-01-23 09:56 +0000
            Re: LongPtr Deanna Earley <dee.earley@icode.co.uk> - 2014-01-23 09:55 +0000
              Re: LongPtr GS <gs@somewhere.net> - 2014-01-23 10:41 -0500
        Re: LongPtr Tony Toews <ttoews@telusplanet.net> - 2014-01-22 15:03 -0700
          Re: LongPtr GS <gs@somewhere.net> - 2014-01-22 17:14 -0500
          Re: LongPtr ralph <nt_consulting@yahoo.com> - 2014-01-22 16:53 -0600
    Re: LongPtr GS <gs@somewhere.net> - 2014-02-24 17:21 -0500

#1996 — LongPtr

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 (dee.earley@icode.co.uk)
iCatcher Development Team
http://www.icode.co.uk/icatcher/

iCode Systems

(Replies direct to my email address will be ignored. Please reply to the 
group.)

[toc] | [next] | [standalone]

#1997

On 22/01/2014 14:22, Deanna Earley wrote:
> 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 :(

-- 
Deanna Earley (dee.earley@icode.co.uk)
iCatcher Development Team
http://www.icode.co.uk/icatcher/

iCode Systems

(Replies direct to my email address will be ignored. Please reply to the 
group.)

[toc] | [prev] | [next] | [standalone]

#1998

> On 22/01/2014 14:22, Deanna Earley wrote:
>> 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 :(

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

[toc] | [prev] | [next] | [standalone]

#1999

On Wed, 22 Jan 2014 12:09:03 -0500, GS <gs@somewhere.net> wrote:

>> On 22/01/2014 14:22, Deanna Earley wrote:
>>> 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 :(
>
>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".]

[toc] | [prev] | [next] | [standalone]

#2000

> On Wed, 22 Jan 2014 12:09:03 -0500, GS <gs@somewhere.net> wrote:
>
>>> On 22/01/2014 14:22, Deanna Earley wrote:
>>>> 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 :(
>> 
>> 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!
>
> 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

[toc] | [prev] | [next] | [standalone]

#2002

On Wed, 22 Jan 2014 16:49:17 -0500, GS <gs@somewhere.net> wrote:


>
>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

[toc] | [prev] | [next] | [standalone]

#2004

> 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

[toc] | [prev] | [next] | [standalone]

#2007

On 22/01/2014 22:16, GS wrote:
>> 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 (dee.earley@icode.co.uk)
iCatcher Development Team
http://www.icode.co.uk/icatcher/

iCode Systems

(Replies direct to my email address will be ignored. Please reply to the 
group.)

[toc] | [prev] | [next] | [standalone]

#2006

On 22/01/2014 21:49, GS wrote:
> 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)

-- 
Deanna Earley (dee.earley@icode.co.uk)
iCatcher Development Team
http://www.icode.co.uk/icatcher/

iCode Systems

(Replies direct to my email address will be ignored. Please reply to the 
group.)

[toc] | [prev] | [next] | [standalone]

#2008

> On 22/01/2014 21:49, GS wrote:
>> 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

[toc] | [prev] | [next] | [standalone]

#2001

On Wed, 22 Jan 2014 12:09:03 -0500, GS <gs@somewhere.net> wrote:
  
>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

[toc] | [prev] | [next] | [standalone]

#2003

> On Wed, 22 Jan 2014 12:09:03 -0500, GS <gs@somewhere.net> wrote:
>   
>> 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

[toc] | [prev] | [next] | [standalone]

#2005

On Wed, 22 Jan 2014 15:03:23 -0700, Tony Toews
<ttoews@telusplanet.net> wrote:

>On Wed, 22 Jan 2014 12:09:03 -0500, GS <gs@somewhere.net> wrote:
>  
>>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

[toc] | [prev] | [next] | [standalone]

#2009

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.

-- 
Garry

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.basic.visual.misc

csiph-web