I found a way to retrieve GPS information from the EXIF at https://www.everythingaccess.com/tutorials.asp?ID=Extracting-GPS-data-from-JPEG-files.
You can download the original Access files from https://www.everythingaccess.com/downloads/GPSExifReader.zip
I imported these VBA for Access Class Modules into Excel. I can retrieve all the GPS information EXCEPT the Decimal GPS Longitude.
As I understand this, the coder (Wayne Phillips) is executing code in the machine's memory to create a virtual COM object from the images, thus exposing the EXIF properties.
Everything runs, except the Call VCOMObject.AssignVar(GPSLongitudeDecimal, VCOMObject.GPSLongitudeDecimal) which is in the Property Get GPSLongitudeDecimal() As Variant procedure.
It crashes my Excel 2013 then restarts it. Tried commenting out the offending Call and works on every Property Get procedure. It's just the Longitude one that crashes without any apparent error being raised.
Thought it might be something weird on that longitude exif parameter so I tried with different jpegs, and with different jpegs from different cameras and the same thing happens.
Since this is an intricate piece of Class Modules voodoo, I'm providing a link to my Excel file (https://yiqyyh.s.cld.pt) just click "Download" on the left hand side of the webpage. The Rar file also has three test images with GPS information on their EXIF.
The easier way to test is by running the UserForm1 UserForm and clicking CommanButton1. This will open a browse window to choose an image. If the textbox gets populated, then nothing bad happened, but if it crashes that's my problem.
EDIT: I tried another machine and Excel 2013 crashed.
EDIT2: The other machine is in my work network. I tried running this on my home PC, also running Excel 2013, and IT WORKED. I need to run this at work.
I had the exact same problem as yours:
On 32bit versions of Office, the GPSExifReader worked fine. On 64bit versions, it froze when retrieving the LongitudeDecimal property (latitude and everything else worked fine).
I solved my problem by using another of Wayne Phillips' excellent tools & tutorials. The VBA modules downloadable from that link drag effortlessly into Excel and the tutorial makes it easy to write a macro that returns latitude and longitude.
Related
I was hoping someone could kindly help me with this issue. I have never faced this before and I am not able to solve it.
We have an Excel file on the network, that up to 10 people daily use, with Excel 365. The file contains a macro that connect to SAP. Until 3 weeks ago, everything was ok, and has been ok for over 6 years.
Now, we hired a new team member, who was given a new PC.
When our new team member tries to open the file on her new machine, there is first a message mentioning there is a problem with the file and proposing to try to recover as much as we can (see picture 1).
Then when she chooses "Yes", she gets another error message mentioning that the file is locked by 'another user'. Oddly enough, it says 'another user', and not the name of that user, and we tested and are 100% nobody else is using the file.
If she then select "Notify" or "Read only", another message pops up, info message from SAP Analysis for Windows.
Finally after she clicks 'OK', the file gets finally opened, but all macro are removed from it. There is a message about the repair:
The log file is added at the end of this post.
We don't understand where the issue exactly is, this is what we tested:
the same new users recently hired can use the file with the macro without any issue on another machine
users that could use the file on their machine, can't on the new machine of our new colleague (for the test, they log in with their own credentials)
other macro files can be opened without any problem on the computer of our new colleague
we have fully reinstalled the computer, and still it bugs...
Log message:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<recoveryLog xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main"><logFileName>error242560_01.xml</logFileName><summary>Errors were detected in file 'S:\MyDistriplus\DI SAP OPERATIONS\Création articles\Templates Création\TEst (2).xlsm'</summary><removedParts><removedPart>Removed Part: /xl/vbaProject.bin part. (Visual Basic for Applications (VBA))</removedPart></removedParts></recoveryLog>
The problem is with the machine (the new computer).
Although you've performed a clean installation (reinstalled), you probably installed the same (probably corrupted) version of Windows and Office.
Try to open OneDrive and change this setting:
Try to install the same version of Windows and Office that's installed on the rest of the computers.
Note: Make sure to include all needed apps, addons, and files to the problematic device.
I had a similar issue, although not the locked by another user dialog. Losing the VBA made no sense to me. It turned out my issue was from duplicating a sheet in VBA that contained an image.
I think I was creating a duplicate ListObject entry for the picture, which would crash excel. My solution was to duplicate the image separately.
If your code is duplicating sheets, try removing any ListObjects and see if the problem persists.
I have an Excel Add-in (with a Userform) which connects to an Access database (using DAO) to perform various functions. I've been using this combo for over a decade. Neither the code in Excel nor the database have been changed recently. Just last week, a user reported that one of their functions was taking much longer than usual, so I looked into it. It ended up that the function itself ran just fine, but when the code was cleaning up and ran db.Close it hung up. It doesn't produce an error, it still eventually succeeds, but it takes around a minute to close the db and move on.
I'll go through all of the symptoms and attempted solutions to see if anyone else has any ideas because I'm at a loss.
This only happens when you run db.Execute. I can open the database and close it right away and it closes just fine. If I open it, run a SELECT query to populate a recordset, then close it, it also closes just fine. But if I open it and run a single UPDATE/SELECT INTO/INSERT/ALTER/DROP statement, the Close method will take a minute to run.
My first thought was to compact the db. I cleared out several unused, old tables and compact/repaired, but this did nothing. Same problem.
My next attempt was to recreate the db. I made a brand new TEST db, imported all of the tables from the old one, pointed my Excel Add-in at the new db and did the same tests. Same results.
My next attempt was to try moving it to a local drive (it's on a network share). This slightly reduced the hang at Close, but it's still there. Not that it matters, because this db has to be hosted on a network share.
My next attempt was to delete a bunch of tables from my TEST database. I cleared out about half of them and the hang at Close was reduced a good deal. Clearing out even more reduced it even more. Deleting all but one table eliminated it. So now I know my problem has to do with the size of the db, but why? It maxed out at 500MB after the compact, which isn't that large. It's been running just fine for years. Why all of a sudden would the size/number of tables be such a huge issue? I obviously can't delete all of the tables in the production database just to solve an issue with Closing the connection.
As I mentioned, this code has been around a long time and the prod db was actually in Access 2000 format (mdb), so my next attempt was to change the format. I tried importing it all into both an Access 2003 format (mdb) and the latest Access 2016 format (accdb). The results were the same.
On a lark, I figured I'd trying hitting the db from somewhere other than the Add-in (on the off chance that the problem was in my Excel file). I copied and pasted my test code into a Word 2016 module... and it ran just fine.
That's odd.
So then I tried a brand new Excel file. Also ran just fine.
So I go back to my Add-in and try the code pasted into a Module.
Again, runs fine.
??
So I open the Userform and run my test code again. Hangs up.
??????
I create a brand new Excel file, make an empty Userform, paste my test code in the form's Initialize event.... hangs up.
I immediately run that same code in a Module afterwards... still hangs up. Even though a minute ago it ran just fine in a module in a different file.
But if I close the file, open a new one, paste in the code WITHOUT opening the Userform, and run it, it works fine. Creating/opening a userform will cause all subsequent attempts to run the code to hang.
So here's the Cliff's Notes version:
Excel 2016 DAO connection to large-ish Access database hangs on db.Close under the following circumstances:
1) The db is large (deleting most of the tables helps but obviously isn't a solution).
2) You have opened any Userform at any time during your Excel session. All attempts during OR after the opening of the form, no matter where the code is run from, will hang. Running the code before opening a Userform does not hang.
These results are duplicated on multiple Windows 7 machines, all with what appear to be the latest updates to Office.
EDIT: I was able to try this out on a remote machine running Excel 2013 and there is no hang (using the original Add-in/db that first exhibited the problem). However, that machine is in our data center which is the same place that the network shares are located, so there are at least two possible reasons why it doesn't hang: 1) Different version of Excel and 2) Different/faster network connection.
If you're wondering why I'm using DAO instead of ADO, it's because of what these functions do (lots of stuff with looping through Tabledefs to modify indexes and even create/modify the table Description, which can't be accessed via ADO. If it weren't for all that, I'd just switch to ADO and be done with it. It's possible that I might be able to come up with ADO alternatives/work-arounds for everything that it's currently doing, but I'd rather not rewrite this entire Add-in if I can help it.
I'm at a complete loss on this one, so if anyone has any ideas, I'm all ears.
I am using SAP crystal reports for Visual studio 2010 in my application. In one of my report I have used images. I am getting image including data in my print preview in report viewer. And also I am able to take prints with data and Images in my environment. But in client place they are telling for some prints the image portion is not getting printed. I am unable to get the exact reason from my searches in internet. So If anybody has faced similar issue please be kind to help me out of this.
The picture is of IOEobject and is placed in designer by selecting the file in design time.
Is it because of the any of the reasons given below
I have scaled the actual Image to X : 44% & Y : 44%.
Due to the image format.
Or due to the printer configuration in the clients' environment.
I would start by assuming the problem is the picture they are printing.
The answer to your problem is likely proper troubleshooting:
Can they replicate the issue with 100% accuracy (meaning, is it refusing to print a specific image)?
If so, get the image and verify that it is supported. A quick Google shows gifs are not supported.
Try to print the same image yourself and see if it works?
Verify printer drivers etc.
The issue:
Similar to this issue but unable to find a solution I am trying to figure out how to fix this bug:
Viewing an object in Locals or Watch window causes excel to crash
The custom class is as wrapper for ADO execution allowing us to use a separate class to maintain our SQL code and execute it within the wrapper to keep error handling for MS Access ADO execution in one neat place.
This has been great for logging and debugging purposes until a few days ago I noticed trying to expand the node for the custom class in the Locals or Watch windows in the VBA editor cause Excel to silent crash after a 5 second hang and restart with the file recovery window.
Unfortunately the code is company sensitive so I may not be able to paste any in but if there are any ideas as to what might cause it I may be able to find the source and report back.
Has anyone else experienced this issue?
Update: New symptom - During debugging and comparing the text between an older build and the new one I found that the Locals window goes empty (clears of all objects) just after the hang stops and before the crash occurs.
Fixes I have tried:
Rebuilding VBA project and fixing all known compile errors (to eliminate simple vba errors)
Exporting all classes and modules - reimporting into new workbook (to eliminate the workbook file being corrupt)
Copying class and module text into notepad and clearing all formatting - pasting into new workbook (in an attempt to remove corrupt class data)
Disabling any reference to other custom classes to narrow down to a single class.
I appreciate your help and hope my issue can shed some light on it for others.
You can try below things. I hope any one of them work for you. If it still it does not works i request you to
simulate the similar issue for demo and share the code.
Possible issues with add-ins. Try to remove your addins (uninstall
the com addins) and run the code and check if you are still having
the issue.Disabling add-ins is a good test because it let you narrow
the choice of which add-in is causing the crash.
Check whether your antivirus software is up to date or is conflicting
with Excel. If your antivirus software is not up to date, Excel may
not function correctly.
Kindly run the macro on single instance of excel and check if you are
still having the issue. By single instance i mean when you go to task
manager processes tab where only one image name with excel.exe should
appear.
Verify/install the latest window updates
Try to run the same macro on other pc or other version of excel
Use mztools andin and review your code
We are using a set of Excel files on several machines in our company. These files contain a VBA application which utilizes a couple of ActiveX control objects from mscomct2.ocx library (namely, MonthView and DateTimePicker). ActiveX objects are to be displayed in UserForm. Unfortunately the portability of these files seems limited in a very peculiar way.
There appears to be 2 groups of machines:
Group A: I can create a Excel file containing MonthView on such machine and work with it on any Group A PC. But when I try to open this file on any machine from Group B, I'm getting a Could not load an object because it is not available on this machine error. However, files with the same ActiveX created on Group B machines work normaly on A machines.
Group B: File with an ActiveX in question created on these machines work everywhere (i.e. on any A and B machine). But, as I said earlier, B machines give the error mentioned above when the file with ActiveX saved on A machine is opened.
In one sentence: files created on A machine work only on other A's, files created on B's work everywhere!
The strangest thing here is that every machine has mscomct2.ocx registered (once again: I can create the form with the MonthView on any machine in question!). The .ocx itself is in place on each machine and the whole set of registry keys is present (CLSIDs for controls classes, IIDs, typelib ID...). In addition, the data in these registry keys seem to be the same on A and B group machines (GUIDs, ProgIDs, versions etc.). There are slight differences in description strings (values like "Microsoft MonthView Control 6.0 (SP6)") on some machines but this does not seem to affect the situation (some machines in B group have such descriptions different but files created on them still work everywhere).
Naturally, thanks to Murphy's law, the machine I use to edit these Excel files belongs to Group A, so files saved here are 'unportable' to B machines...
The OS and Excel versions don't seem to affect the situation. For example, one of B machines is working under Win 7 64 bit (Excel 2007), while most others group A and B machines are Win XP Prof (32 bit) SP3, with Excel 2003 installed. So it seems that OS and Excel versions don't affect compatibility and the problem is somehow connected with ActiveX.
The only ActiveX-related difference between A and B groups I found is the file version of mscomct2.ocx: at least several of A machines have version 6.1.x.x, while Group B has 6.0.x.x. I don't see how can such difference cause problems (ActiveX are COM objects after all, and according to registry key values, the exposed typelib, com objects and interfaces seem to be the same in all cases). Nevertheless I tried to replace my 6.1.x.x ocx with 6.0.x.x version... and ran into more trouble. What I did is:
regsvr32 /u mscomct2.ocx - completed successfully
Replaced the mscomct2.ocx with file of 6.0.x.x version
regsvr32 mscomct2.ocx - completed successfully
After these steps I tried to make an Excel file with single form containing the MonthView. But when I tried to place a control in the form I've got a messagebox with error Class not registered. This is really strange cause everything seem to be registered: the control class, its interfaces, typelib (yes, I've checked the registry to be sure). But still the error was there.
After that I did the unregister/replace/register procedure again to go back to my original 6.1.x.x file. That took me back to the original SNAFU situation: I could again install ActiveX to user form and use it, but the Group B machines still gave the error on files saved by my machine.
I assume that the problem of files-with-ActiveX portability and the problem of ocx registration are somehow connected, but I don't see how. Perhaps there are some additional requirements for registration of an ActiveX in Excel VBA which I don't know...
The only thing I need is to have the ActiveX object contaned in my Excel file compatible with other machines. Can anyone help me with that?
I think one group (probably "A") has this installed: http://www.microsoft.com/download/en/details.aspx?id=10019, another one don't.