Tracking down VBA reference DLLs and getting them to work
I may having difficulty with a search for reference files, because I am being confounded by the redesign by Microsoft for the search engine in windows 7.
Since all my efforts so far to reliably get Excel to talk to my BricscCAD v14 have eventually failed, I am trying to nail down where the reference files are located. And especially to find if there were any duplicates. A search by Windows 7 search function using _file:bricscad*.dll **_ only shows one file, _bricscadapi.dll_ located in _C:\Program Files (x86)\Bricsys\BricsCAD V14 en_US**_
I had hoped it would bring up "BricsCAD Db 14.0" and "BricsCAD APP"
The .dll extension is actually a guess on my part. I don't know for sure what the file type for a reference in VBA should look like. Perhaps it is embedded in the bricscadapi.dll file. In VBA Tools/References menu, there is the option to browse for the files. It shows obj,.tlb,*.dll as the main file types. But, the pull-down file type menu, also allows .ocx and .exe.
I tried a search for _file:bricscad*.* **_ but oddly enough, it didn't find the file I found in my search with the .dlll extension. Perhaps a wildcard is no longer permitted in both the file name and the extension. A search for _file:bricscad* _ brought up many files, but only the main BricsCAD.exe program file and the _file:bricscad*.dll **_ I found earlier, had viable extensions.
What am I doing wrong? What should the file names for the BricsCAD references look like?
Sorry for the messed up formatting. Ignore the bold and italics. It is pretty much all random. Markdown doesn't seem to work properly, and there is no one "erase formatting" feature on the forum.
-Joe
Comments
-
Reading other web pages that comment in regards to VBA failing to find a reference, I see now that if it does not find it, then when I look at the references menu, it will say "not found".
In my case, they show up on the list looking like they have been found. So, perhaps I am just looking for multiple versions, and perhaps one of them is and older version that has a bug, or does not successfully work with the most current v14 of BricsCAD.
-Joe
0 -
I know from a .NET perspective, the COM DLLs to reference are axbricscadapp1.dll and axbricscaddb1.dll, located in the install folder.
Also you can find axbricscadapp1.tlb and axbricscaddb1.tlb in the BRX SDKCheers!
0 -
Thank you Daniel. I can now confirm that I only have one copy of these reference files. So, the trouble is elsewhere.
-Joe
0 -
After using a registry search and delete tool, I was able to remove all BricsCAD info that is left behind after an uninstall. Then, I re-installed, hoping that this would wipe any references to errant references.
I tried it out by just running my Excel routine, which already had the references selected. But, it did not work, with my error-trapping routine saying "BricsCAD did not start", even though BricsCAD was already running. So, it apparently can't "see" the application.
I should first mention that I have no idea why there are both a .dll and a .tlb file for the references. VBA seems to accept either as a reference. My first guess is that they both do the same thing, but just in a different format, in the same way that a .dwg and a .dxf file for a drawing can be the same.
Searching for the files, axbricscadapp1.dll axbricscaddb1.dll and their .tlb equivalent, I found both kinds. They were in different directories. Since my efforts to use the .dll versions, I decided to try the .tlb version. But, the first time I tried toI select the .tlb file, Visual Basic reports, That it cannot load a reference that is already loaded. I re-started Excel, and the second time it accepted them.
So, I saved, and exited Excel, and restarted it. Running my routine generated the same "BricsCAD did not start" error.
I wish I didn't have to do all this trial-and-error, but this seems to be the sort of problem that escapes logic, even for experts.
My next attempt is to try the .dll files. But, I go the same "BricsCAD did not start" error.
In all cases, I moved the references as far up on the list of references as VBA would allow. I also tried to run the routine without BricsCAD already running.
The only other thing I have left to try, is to convert my code to run from within BricsCAD, and then have it look at the data in Excel. I suppose yet another approach is to use Excel to create a .csv file that the BricsCAD VBA can look at. But, since I am dealing with a script, that takes a great deal of trial-and-error to get right. And having to re-create the .csv file for every iteration would probably make the approach not viable.
Can anyone comment on the difference between a .dll and a .tlb reference?
-joe
0 -
Have you tried connecting to Excel with Lisp using ActiveX controls?
Kevin
0 -
I have not attempted anything in BricsCAD yet. I am not really familiar with LISP, so have been avoiding that route.
This project being done in a time when I had the time to invest in it. So, it may be tabled for a while, especially since I fear that programming in BricsCAD to read Excel may prove to be another rabbit trail.
-joe
0 -
It is really pretty straight forward with Lisp. You can access the excel file via Lisp inside BricCAD to read and write data to the Excel File, then use Lisp to make the changes in your drawing if needed.....
Kevin
0 -
Now that I think about using LISP, I recall that there is no LISP programming environment provided by Bricsys. You are left with notepad, or in my case Notepad++, but that is not really a good way to program, when compared to something like the VBA programming environment.
-Joe
0 -
I use UltraEdit for my lisp development. It has parenthesis matching and syntax highlighting, which is a must. No, it's not integrated into BricsCAD, so you have to be somewhat inventive with debugging, but it's not impossible.
Kevin
0 -
I posted this on another related thread, but didn't want to leave this thread without the note.
I found the cause of the problem. Roy Klein Gebbinck had sent me an example in LibreOffice's Calc program. However, I got an error until I set LibreOffice Calc to "Run as Administrator". I did a similar change to Excel, and suddenly my VBA to talk to BricsCAD was now working.
My system administrator had some security settings, where some programs have to be set to "run as administrator" to be able to do certain things. It worked at first, perhaps because Windows had not initially noticed, or because Windows update had changed something.
I should mention that getting Excel to run as administrator took more than just changing the setting in the shortcut. In the shortcut, it is ghosted. So, you first have to track down the Excel.exe file, and change that to run as administrator. Then, you will be able to edit the shortcut and set it to run as administrator.
-Joe
0 -
Dear Joe,
"never trust the Microsoft desktop icons" :-)
Personally, I always crop the .exe to desktop as shortcut, then you have full control.For the "run as admin" problem
yes, Microsoft changed the HKEY_CLASSES_ROOT access rights from "standard user" (Win2000) to "power user" (WinXP) to "admin" (Vista + higher), to provide more security ...
what they overlooked is : HKCR is the main place to register COM servers ... and each COM server is required (also by Microsoft COM design guides) to always re-register the COM server at each application startup
(another application could have registered as server, for same object/data type, in-between ...)Since then, having COM servers (and clients as well) working properly is a nightmare - simply requires "admin" rights - no other solution
(or, what I did locally : I changed HKCR + all sub-keys back to "standard user" access rights :-) works perfectly as well, but ruines Microsoft's security attempt here).many greetings !
0 -
I should have mentioned that the user has to have Admin rights. BricsCAD itself, at least on v14 requires this as well. And one side-effect of changing a program to run as administrator is that every time you start a program like this, you get a window popping up asking, "Do you want this program to make changes to this computer?".
So, now I am clicking the "OK" button many times in a day, making it into a reflect that I don't even bother to think about. Of course, this negates the security feature, because if a program were to run that I did not request, such as might be done by a virus. I would probably automatically click OK without even thinking. Sometimes security attempts cause less security.
-Joe
0 -
Dear Joe,
yes, all agreed ... as mentioned, Microsoft introduced this problem, by increasing access rights to HKCR, where COM servers will register ...
and by that change (which is clearly an advantage in security, no doubts), they also damaged some fundamental COM designs ...
as result, we run into the trouble.All works fine with COM - but only, if you have exactly and *only 1 BricsCAD version installed ... if you have (i.e.) V14 and V16, then you will have a problem, if external COM clients want to access the running BricsCAD instance, via COM ... COM design works (in many parts) using the "last-run" instance ...
Normally, the BricsCAD installer does effectively register the COM interface, the installer gets elevated rights - so far, no problem;
if you afterwards install a higher BricsCAD version, then the installer will register that newer COM interface ... hence, an external client (Excel) will always start that last-installed BricsCAD - regardless if you run the older version ...Therefore, Microsofts initial design to access the "last-run" server (assuming, that server follows the Microsoft design requirement to always re-register during startup) was nice - but no longer works that way, as HKCR requires admin rights ...
so alltogether, there is a dilemma - higher security requests vs. older design, both conflicts, and COM was never redesigned to match the new strategy.many greetings :-)
0
