UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
 
   Reply to this topicStart new topic
> File Dialogue Not Working In 64 Bit, Access 2016    
 
   
atanask
post Apr 9 2020, 02:20 PM
Post#1



Posts: 6
Joined: 1-March 20



Hi,

I have a form in Access 2010, with a button to open file browser and select files to insert their names in a table. All works OK with the following code:

Private Sub Command7_Click()
Dim F As Object

Set F = Application.FileDialog(3)

F.AllowMultiSelect = True

If F.Show Then
For i = 1 To F.SelectedItems.Count
sFile = Filename(F.SelectedItems(i), sPath)
Me.ImageFile = sFile
Next
End If

End Sub

Public Function Filename(ByVal strPath As String, sPath) As String
sPath = Left(strPath, InStrRev(strPath, "\"))
Filename = Mid(strPath, InStrRev(strPath, "\") + 1)
End Function

= = =

I created a blank database in Access 2019 64 bit, imported all objects from the 2010 32 bit version,
but now the button does not activate the file browser.
All settings are identical.

Microsoft Office 16.0 Object Library is selected

Please, suggest a solution


Go to the top of the page
 
theDBguy
post Apr 9 2020, 02:22 PM
Post#2


UA Moderator
Posts: 78,121
Joined: 19-June 07
From: SunnySandyEggo


Hi. Welcome to UtterAccess! welcome2UA.gif

If you go to Debug > Compile, do you get any errors? If so, can you post a screenshot of the error message and the code with the problem? Thanks.

--------------------
Just my 2 cents... "And if I claim to be a wise man, it surely means that I don't know" - Kansas
Access Website | Access Blog | Email
Go to the top of the page
 
atanask
post Apr 9 2020, 02:40 PM
Post#3



Posts: 6
Joined: 1-March 20



Thank You Sir,

I get an error, but for another modul
Attached File(s)
Attached File  compileerror.png ( 75.44K )Number of downloads: 13
 
Go to the top of the page
 
theDBguy
post Apr 9 2020, 03:07 PM
Post#4


UA Moderator
Posts: 78,121
Joined: 19-June 07
From: SunnySandyEggo


So, although you were using the FileDialog object to browse for files, it seems you are using API to select fonts. You will have to modify all your API declarations to work with 64-bit Access. Do you know how to do that?

--------------------
Just my 2 cents... "And if I claim to be a wise man, it surely means that I don't know" - Kansas
Access Website | Access Blog | Email
Go to the top of the page
 
DanielPineault
post Apr 9 2020, 03:13 PM
Post#5


UtterAccess VIP
Posts: 7,343
Joined: 30-June 11



Just in case you aren't aware of how to convert them, here is the proper 64-bit declaration for the the function currently being flagged

CODE
Declare PtrSafe Function GlobalAlloc Lib "kernel32" Alias "GlobalAlloc" (ByVal wFlags As Long, ByVal dwBytes As LongPtr) As LongPtr


and here are all the 64-bit declarations for what I could see in your image
CODE
Declare PtrSafe Function GlobalLock Lib "kernel32" Alias "GlobalLock" (ByVal hMem As LongPtr) As LongPtr
Declare PtrSafe Function GlobalAlloc Lib "kernel32" Alias "GlobalAlloc" (ByVal wFlags As Long, ByVal dwBytes As LongPtr) As LongPtr
Declare PtrSafe Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (Destination As Any, Source As Any, ByVal Length As LongPtr)
Declare PtrSafe Function GetDeviceCaps Lib "gdi32" Alias "GetDeviceCaps" (ByVal hdc As LongPtr, ByVal nIndex As Long) As Long
Declare PtrSafe Function GetDC Lib "user32" Alias "GetDC" (ByVal hwnd As LongPtr) As LongPtr
Declare PtrSafe Function MulDiv Lib "kernel32" Alias "MulDiv" (ByVal nNumber As Long, ByVal nNumerator As Long, ByVal nDenominator As Long) As Long



I always have to ask, why not simply stick with 32-bit version of Office? For the vast majority of users there is no reason for 64-bit and it causes a lot of unnecessary headaches.

--------------------
Daniel Pineault (2010-2019 Microsoft MVP, UA VIP, EE Distinguished Expert 2018)
Professional Help: https://www.cardaconsultants.com
Free MS Access Code, Tips, Tricks and Samples: https://www.devhut.net

* Design should never say "Look at me". It should always say "Look at this". -- David Craib
* A user interface is like a joke, if you have to explain it, it's not that good! -- Martin LeBlanc


All code samples, demonstration databases, links,... are provided 'AS IS' and are to be used at your own risk! Take the necessary steps to check, validate ...(you are responsible for your choices and actions)
Go to the top of the page
 
atanask
post Apr 9 2020, 03:22 PM
Post#6



Posts: 6
Joined: 1-March 20



No, smile.gif.

The Fonts option was an experiment.
I deleted the fonts-related modules and forms, and this time there were not errors when I compiled the database.
Still, no File Picker...
Go to the top of the page
 
atanask
post Apr 9 2020, 03:37 PM
Post#7



Posts: 6
Joined: 1-March 20



Thanks,

Regarding 64 bit - our museum will receive donation for Access 2019 licenses and I was experimenting with 64 bit.

I was able to create quite a functional museum information system in Access 2010
(with many samples of ready made code solutions - I am archaeologist, not a programmer smile.gif)
Go to the top of the page
 
theDBguy
post Apr 9 2020, 03:42 PM
Post#8


UA Moderator
Posts: 78,121
Joined: 19-June 07
From: SunnySandyEggo


Re: 64-bit. If you can avoid it, I would recommend only installing 32-bit versions of Access. Otherwise, you may have to clean out all your experimental code and bring it back down to the minimum that makes it work.

--------------------
Just my 2 cents... "And if I claim to be a wise man, it surely means that I don't know" - Kansas
Access Website | Access Blog | Email
Go to the top of the page
 
atanask
post Apr 9 2020, 04:55 PM
Post#9



Posts: 6
Joined: 1-March 20



Surprise, installed 32 bit version.

2010 accdb file, opened in 2019 - all works properly.

Empty 2019 file with all objects imported from 2010 - the old problem persist - the file browser can not be activated

= = =

I suppose we can continue to use the 2010 file in Access 2019 if there will be no design and code modifications.

But what will happen if I try new tricks? smile.gif
Go to the top of the page
 
BruceM
post Apr 10 2020, 07:56 AM
Post#10


UtterAccess VIP
Posts: 8,110
Joined: 24-May 10
From: Downeast Maine


64 bit Access was introduced with the 2010 version. At the same time the VBA version changed from 6 to 7. VBA 7 introduced LongPtr, PtrSafe functions, and a LongLong integer that most people will never need.

Aside from LongLong, the other changes work equally well with 32 and 64 bit versions of Access. A pointer or handle is a memory address rather than being strictly data. These are often identified in function declarations as hWnd, hMem, etc., but there are no invariable rules. In 32 bit VBA that address is 32 bits wide; in 64 bit VBA it is 64 bits. If you pass Long (a 32 bit Integer) to a 64 bit memory location, Access doesn't know what to do with the leftover space, so to speak. It could happen the other way around, but I expect that is less likely.

Declaring the object (the memory location) as LongPtr tells VBA to allocate a memory location that is the correct size for the "bitness" of the application. Declaring the function as PtrSafe means it is "safe" to use pointers or handles, which will be sized appropriately.

If there are no APIs it most likely will not be necessary to know this. If all of the installations are 32 bit most likely it won't matter because a Long passed to a 32 bit memory location is not a problem. Likewise for Long as the function return value.

A rather frequent misunderstanding is that it is necessary to do a conditional compilation (explained and demonstrated here) for 64 bit. Except in rare cases, it is not. Declaring PtrSafe functions and using LongPtr do all that is needed in both 32 and 64 bit Access from Access 2010 onward.

If your code has APIs, and there may be users other than yourself or whose Access installations you can't control, you should convert to PtrSafe and LongPtr. API documentation should have this information. UtterAccess has quite a good library, and there are many other sources. Although there is no real need for 64 bit Office applications for most users, the "bigger is better" philosophy cannot be overcome. Users will eventually have 64 bit Access.

BTW, if any users have Access 2007 or earlier, PtrSafe and LongPtr will fail. VBA versions earlier than 7 don't understand those terms. That's where the conditional VBA 7 compilation, explained in the first link above, comes into play.

More than you wanted to know, perhaps, but I tried to keep it succinct.
Go to the top of the page
 
atanask
post Apr 10 2020, 02:47 PM
Post#11



Posts: 6
Joined: 1-March 20



Thanks for your time.
Frankly, all this is beyond my qualification.

My first love with databases started with Access 2.0. In the years, I learned, by examples, solutions for our needs.

So far we have a working 2010 database, processing 27000 museum artifacts with all the necessary museum output documentation, with correlated images for most of them, in multi-user mode (peer-to-peer network, back-end on a shared folder).

I just like adding more and more functionality. In my next life, I would like to be an Access programmer smile.gif
Go to the top of the page
 
DanielPineault
post Apr 12 2020, 08:34 AM
Post#12


UtterAccess VIP
Posts: 7,343
Joined: 30-June 11



If your post you db (removing confidential info) we can take a closer look at it.

--------------------
Daniel Pineault (2010-2019 Microsoft MVP, UA VIP, EE Distinguished Expert 2018)
Professional Help: https://www.cardaconsultants.com
Free MS Access Code, Tips, Tricks and Samples: https://www.devhut.net

* Design should never say "Look at me". It should always say "Look at this". -- David Craib
* A user interface is like a joke, if you have to explain it, it's not that good! -- Martin LeBlanc


All code samples, demonstration databases, links,... are provided 'AS IS' and are to be used at your own risk! Take the necessary steps to check, validate ...(you are responsible for your choices and actions)
Go to the top of the page
 
tina t
post Apr 12 2020, 10:13 AM
Post#13



Posts: 6,601
Joined: 11-November 10
From: SoCal, USA


QUOTE
I just like adding more and more functionality. In my next life, I would like to be an Access programmer

you already are, hon. :) tina

--------------------
"the wheel never stops turning"
Go to the top of the page
 
GroverParkGeorge
post Apr 12 2020, 10:42 AM
Post#14


UA Admin
Posts: 37,265
Joined: 20-June 02
From: Newcastle, WA


A surprising number of us followed that path. Once you realize the potential of a relational database application and the fact that YOU can do it yourself, it's hard to resist.

--------------------
My Real Name Is George. Grover Park Consulting is where I did business for 20 years.
How to Ask a Good Question
Beginning SQL Server
Go to the top of the page
 


Custom Search


RSSSearch   Top   Lo-Fi    30th May 2020 - 10:04 AM