Prev: Re-Establishing Connection to Back-End
Next: Late Binding Issue
From: Yuval Nir on 21 Jan 2010 19:48
On Jan 21, 1:35 pm, Banana <Ban...(a)Republic.com> wrote:
> David W. Fenton wrote:
> > Banana <Ban...(a)Republic.com> wrote in
> >news:4B57E480.3010408(a)Republic.com:
>
> >> So, basically, add "PtrSafe", and change "Long" to "LongPtr" for
> >> where handlers or pointers are used or expected. (Don't change
> >> Long parameter if it's not a handler or pointer type)
>
> > And there's no problem with this in 32-bit environments? It seems
> > there *is* a problem, as if I do this, my code won't compile any
> > longer.
>
> The help file suggests using conditional compilation. Furthermore, VBA7
> supports LongPtr for both environments as it is intended to be a
> scalable type (converts to a Long on 32-bit, LongLong on 64-bit).
>
> I've not tested extensively and I don't have a 32-bit Access 2010 handy
> to see how this all would work out. I'm under the impression that when
> using older files, they will run just fine on a 32-bit Access 2010. I'm
> unclear whether 64-bit Access provides some kind of compatibility
> environment for those files but I understand you can take in a older
> file and re-compile it for 64-bit. If the code doesn't contain any API
> calls, then it's completely transparent - just a simple re-compile will
> do. OTOH, with API calls, well, the earlier suggestion applies.
>
> Maybe this will be of interest?
>
> http://www.utteraccess.com/forums/showflat.php?Cat=&Board=93&Number=1...

Just for the record, I have both access 2010 versions on different
machines. 32 bit, upgraded Access 2000 mdb and compiled just fine.
With 64 bit, I am still workingonit, and yes, I do have API calls.
yn
From: David W. Fenton on 22 Jan 2010 16:51
Banana <Banana(a)Republic.com> wrote in
news:4B58AC74.7030405(a)Republic.com:

> David W. Fenton wrote:
>> Banana <Banana(a)Republic.com> wrote in
>> news:4B57E480.3010408(a)Republic.com:
>>
>>> So, basically, add "PtrSafe", and change "Long" to "LongPtr" for
>>> where handlers or pointers are used or expected. (Don't change
>>> Long parameter if it's not a handler or pointer type)
>>
>> And there's no problem with this in 32-bit environments? It seems
>> there *is* a problem, as if I do this, my code won't compile any
>> longer.
>>
>
> The help file suggests using conditional compilation. Furthermore,
> VBA7 supports LongPtr for both environments as it is intended to
> be a scalable type (converts to a Long on 32-bit, LongLong on
> 64-bit).
>
> I've not tested extensively and I don't have a 32-bit Access 2010
> handy to see how this all would work out. I'm under the impression
> that when using older files, they will run just fine on a 32-bit
> Access 2010.

They had better!

> I'm
> unclear whether 64-bit Access provides some kind of compatibility
> environment for those files

Access files are not 32- or 64-bit. But the API calls may be at
issue. Certainly the 16-bit API calls in Access 2 had to be
converted to 32-bit calls when Access 95/97 was released.

> but I understand you can take in a older
> file and re-compile it for 64-bit. If the code doesn't contain any
> API calls, then it's completely transparent - just a simple
> re-compile will do. OTOH, with API calls, well, the earlier
> suggestion applies.
>
> Maybe this will be of interest?
>
> http://www.utteraccess.com/forums/showflat.php?Cat=&Board=93&Number
> =1914261&fpart=1

Yes, a fascinating and informative thread.

All of the API calls I use I've copied from someone else's code,
either on the Access web or from the ADH. I wonder if there could be
an effort made by those who understand the pointer issues to revise
the API calls on the Access web for conditional compilation? I don't
have the knowledge to help with the job myself (my mind glazes over
when I try to comprehend the Windows API documentation), but I sure
do use this stuff (and I have every intention of having A2010 apps
in production use by the end of 2010, a very unusual situation for
me, not matched since A97), and since a large portion of new PCs are
64-bit and are going to ship 64-bit Access, it's going to be an
issue.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
From: David W. Fenton on 22 Jan 2010 16:53
Yuval Nir <ynthevet(a)gmail.com> wrote in
news:b0195c16-3efc-4d26-a147-c133111708a6(a)h2g2000yqj.googlegroups.com
:

> Just for the record, I have both access 2010 versions on different
> machines. 32 bit, upgraded Access 2000 mdb and compiled just fine.
> With 64 bit, I am still workingonit, and yes, I do have API calls.

Hmm. It *should* work in an MDB. It's only an MDE in which it can be
a problem (though I wouldn't want to force recompilation at
runtime).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
From: Banana on 22 Jan 2010 17:02
David W. Fenton wrote:
> Access files are not 32- or 64-bit. But the API calls may be at
> issue. Certainly the 16-bit API calls in Access 2 had to be
> converted to 32-bit calls when Access 95/97 was released.

I think I worded that poorly - it's the VBA within the files that will
be need to be re-compiled between two platforms. I'm under the
impression this is done automatically for non-MDE/non-ACCDE files.

> Yes, a fascinating and informative thread.

Glad it helped.

> All of the API calls I use I've copied from someone else's code,
> either on the Access web or from the ADH. I wonder if there could be
> an effort made by those who understand the pointer issues to revise
> the API calls on the Access web for conditional compilation? I don't
> have the knowledge to help with the job myself (my mind glazes over
> when I try to comprehend the Windows API documentation), but I sure
> do use this stuff (and I have every intention of having A2010 apps
> in production use by the end of 2010, a very unusual situation for
> me, not matched since A97), and since a large portion of new PCs are
> 64-bit and are going to ship 64-bit Access, it's going to be an
> issue.

Last time I looked, I was under the impression that whoever maintained
the http://allapi.mentalis.org/ no longer is actively updating the
lists, and that was AFAIK, one of better API repository for Visual Basic
family language.

I expect the transition will be piecewise. I had a nasty surprise few
weeks when I used a API and found that it no longer works in
Vista/Win7/Win2008 family, due to UAC and had to use a completely
different API. I think back then we were fortunate to be able to ride
the coattail of VB developers who needed APIs far more than Access
developer (no hard fact to back this up, just an haphazard guess on my
part). This is something we'll have to think about, I would imagine.
From: David W. Fenton on 23 Jan 2010 19:26
Banana <Banana(a)Republic.com> wrote in
news:4B5A2090.2050901(a)Republic.com:

> I had a nasty surprise few
> weeks when I used a API and found that it no longer works in
> Vista/Win7/Win2008 family, due to UAC and had to use a completely
> different API.

Someone posted a while back about the change in the API that returns
the location for where you're supposed to put writable application
components. That used to be in All Users\AppData, but now that
folder is read-only, so there's no place to put writable application
data that can be shared between users.

That's unfortunate for Access apps, but not disastrous.

> I think back then we were fortunate to be able to ride
> the coattail of VB developers who needed APIs far more than Access
> developer (no hard fact to back this up, just an haphazard guess
> on my part). This is something we'll have to think about, I would
> imagine.

Yes, it's an unfortunate fact that we seem to be left behind. I
assume MS has a plan for that and that we'll be getting some form of
..NET sometime in the future. I'm not excited about that, but it's
going to be a necessity if Access is going to maintain its
capability for infinite expandability.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Re-Establishing Connection to Back-End
Next: Late Binding Issue