-
January 6th, 2021, 04:39 PM
#16
Re: Excel Automation Headaches
Then try the option "... from registry..." (sorry, i currently do not have any VS on my notebook, therefore cannot be more precise)
Victor Nijegorodov
-
January 7th, 2021, 02:38 AM
#17
Re: Excel Automation Headaches
Originally Posted by jim enright
I get to the point of adding the type lib i cannot find any typelib start with "Microsoft Excel" as per the article:
Do you have Excel installed on your development machine? Are you running on a 64 bit or 32 bit OS? If 64 bit OS, are you compiling for 64bit or 32bit?
-
January 7th, 2021, 04:22 PM
#18
Re: Excel Automation Headaches
the attempt to add excel classes via the class wizard in 2017 uses the "from registry" by default - there are no excel object libraries listed.
when i switch to "from file" there are no entries whatsoever.
-
January 7th, 2021, 04:44 PM
#19
Re: Excel Automation Headaches
Then have a look at the post#17
Victor Nijegorodov
-
January 7th, 2021, 06:18 PM
#20
Re: Excel Automation Headaches
i have looked at 17 - there are no clear cut suggestions on course of action - only to look at things - no idea how to interpret what i would see,
i have also attempted to follow the course of action in this link( with vs2017 but using the mfc dlg app framework)
https://docs.microsoft.com/en-us/pre...e-excel-from-c
it throws errors all over the place: eg
Error (active) E1097 unknown attribute "no_init_all" xlautoole C:\Program Files (x86)\Windows its\10\Include\10.0.18362.0\um\winnt.h 7597
the os is windows 10 64 bit, the excel version from office 2019 is 64 bit, and as best as i can tell the the compiler is produ.cing
64 bit executables because in the configuration properties the Target Platfrom is windows 10 which as best as i can tell form what
ms says is 64 bit. you cannot see me right now but i am on my knees praying to god that ms would not allow this compiler to produce
32 bit exes when as far as i know windows 10 onlu comes in 64 bit. i do not think this is an unreasonable request since it has been
over 50 years since we actually sent a man to the moon and brought him back safely/
Last edited by jim enright; January 7th, 2021 at 06:49 PM.
Reason: add more info
-
January 7th, 2021, 09:11 PM
#21
Re: Excel Automation Headaches
guess we can call off the dogs. was able to get a vs2017 mfc dlg based app to the point that it would open up
excel from office 2019 (which has no worksheets upon opening). i basically had do the following:
1. covnvert all text strings such as "error .." to _T("error ..") (a change that took place after vc6.0
2. convert all MessageBox statements from 4 to 3 args (get rid of the orig arg1 NULL values)
3. make the the third arg MB_OK
4, replace all return values and _exit() statements with "exit(0)" statements
will have to tinker with this since a lot of the common steps such as "delete sheet", "rename sheet", "reposition sheet"
need to be fleshed out. rigght now the demo code only works to open and close the spreadsheet. despite
code indicating it would fill a range of cells with data it did not work. the code ran with out error but simply did not
populate cells so the jury is still out on this being robust solution in the stated environment and windows 10.
however, it does seem to be working without the use of typelibs and import statements etc.
-
January 8th, 2021, 03:06 AM
#22
Re: Excel Automation Headaches
Originally Posted by jim enright
...
4, replace all return values and _exit() statements with "exit(0)" statements
Why "exit(0)"? Why "_exit()"?
Using either of these in MFC application never was a good idea! And it is still a bad idea now!
Victor Nijegorodov
-
January 8th, 2021, 12:12 PM
#23
Re: Excel Automation Headaches
for the simoplke reason it removes that junk form causing compile failures during a time my immediate concern
is to get any semblance of success in getting the excel automation processes running. and even now it is still
a freaking headache. i google and i google and i google some more just to find a way to add another worksheet
to the workbook that appears from the "add" statement from the above article.
still seems to me the best solution would be to somehow make the excel ob library available through the add clsss
wizard that transitioning to vs2017 was supposed to facilitate and/or get a pair of mso.dll and escel.exe files that are internally consistent. that article seemed to have access to a lib that encapsulated the standard operations one would
normally use on workbooks (open,save,add ws, del ws, rename ws etc)
Last edited by jim enright; January 8th, 2021 at 12:17 PM.
Reason: add more info
-
January 9th, 2021, 03:30 AM
#24
Re: Excel Automation Headaches
Originally Posted by jim enright
i have looked at 17 - there are no clear cut suggestions on course of action - only to look at things - no idea how to interpret what i would see,
i have also attempted to follow the course of action in this link( with vs2017 but using the mfc dlg app framework)
https://docs.microsoft.com/en-us/pre...e-excel-from-c
it throws errors all over the place: eg
Error (active) E1097 unknown attribute "no_init_all" xlautoole C:\Program Files (x86)\Windows its\10\Include\10.0.18362.0\um\winnt.h 7597
the os is windows 10 64 bit, the excel version from office 2019 is 64 bit, and as best as i can tell the the compiler is produ.cing
64 bit executables because in the configuration properties the Target Platfrom is windows 10 which as best as i can tell form what
ms says is 64 bit. you cannot see me right now but i am on my knees praying to god that ms would not allow this compiler to produce
32 bit exes when as far as i know windows 10 onlu comes in 64 bit. i do not think this is an unreasonable request since it has been
over 50 years since we actually sent a man to the moon and brought him back safely/
Dude, you are stuck in old technology. Microsoft has moved on. Maybe you should too?
-
January 12th, 2021, 06:28 PM
#25
Re: Excel Automation Headaches
can you be a little more specific? what aspect of this is old technology?
-
January 13th, 2021, 01:10 AM
#26
Re: Excel Automation Headaches
Originally Posted by jim enright
can you be a little more specific? what aspect of this is old technology?
UI with C++ and MFC, COM, to name a few.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|