I want to package my classes (in VBA or VB), but I want to put a lock on them before I do so. I want the computer to return a message similar to one in the Word file attached. Can anybody point me in the right direction? There doesn’t seem to be a lot of help in this regard.
I would need something that would lock just the classes that I have made while still leaving the rest. My understanding is that the mde would compile the whole works, and therefore would not work. Is that correct?
Could you have 2 projects for 1 mdb file? Then I could allow 1 project to be locked (mine) and then the other to be open to everyone
Marty Habicht
An add-in may suit: http://msdn.microsoft.com/en-us/library/aa902693.aspx
You can create an mde and include it as a refernce in other Access applications (code window, Tools-References).
See my Add-in Tips, Hints and Gotchas page for an Access only answer.
A simple solution would be to put the classes in an mde, and then just set a reference to the MDE from the unlocked project. This will give you access to the class, while rendering your source unviewable. This won't stop a determined reverser, but I don't really think a determined reverser is in the threat model:)
Related
I had a "Compile Error: Can't find project or library" error when opening a database that I have programmed on a new workstation (that I do not typically use).
The really odd thing is that the highlighted code is LCase which is something extremely basic. That the reference for this could be missing in even a freshly installed standard edition of MS Access is unlikely.
Having googled this phenomenon I have read that sometimes Excel Files don't grab all necessary refrences when they are copied. Chip Pearson's excellent article explains which references are needed.
So I tried to go check if all references are available, when stranger still, I couldn't even access the Tools>References in Access because it was grayed out.
Why would this happen and how can I fix it?
Any advice or hints on how to investigate this are appreciated.
VBA references are not available for viewing or editing in an .mde or .accde Access database. It must be a .mdb or .accdb to view references.
Sometimes things move quicker than expected. Upon searching yet another time, I found the solution to the problem.
In needed to add VBA infront of UCase, LCase, or Space . Apparently on some machines linking to compiled DLL files causes this problem.
VBA.LCase, etc. solves it.
My overall setup is quite involved, so here is my attempt to pin-point the precise part that I'm stuck on.
For whatever it's worth, I will have much respect for whoever can figure this out. I think that the solution requires an esoteric understanding of Excel Add-Ins.
The Background:
Here is the relevant universe of files that I am dealing with:
Filepath_2\UI_2.xlsm
Filepath_1\CI_1.xlsm
Filepath_1\AI_1.xlam
Filepath_2\CI_2.xlsm
Filepath_2\AI_2.xlam
Filepath_2\UI_2.xlsm is the file that is running the VBA to accomplish the desired file operations on/in the other four aforementioned files.
Filepath_1\CI_1.xlsm contains a reference to Filepath_1\AI_1.xlam.
My goal is to...
Copy Filepath_1\AI_1.xlam to Filepath_2\AI_2.xlam
Copy Filepath_1\CI_1.xlsm to Filepath_2\CI_2.xlsm
Open Filepath_2\AI_2.xlam
Open Filepath_2\CI_2.xlsm
Remove, from Filepath_2\CI_2.xlsm, the reference to Filepath_1\AI_1.xlam
Set, in Filepath_2\CI_2.xlsm, a reference to Filepath_2\AI_2.xlam
... handle business in Filepath_2\CI_2.xlsm ...
Close and delete Filepath_2\CI_2.xlsm and Filepath_2\AI_2.xlam
... and, I am able to accomplish all of the above save for one minor snafu:
The VBA project for Filepath_1\AI_1.xlam is opened upon opening Filepath_2\CI_2.xlsm and I cannot figure out any way to close it.
The Question:
What is the required VBA code to close the VBA project for Filepath_1\AI_1.xlam?
It is worth mentioning that my current inability to close that VBA project is not adversely affecting anything for the time being, so this is really a matter of control and process cleanliness for the longer term. I simply do not want a stray VBA project remaining open.
I can be somewhat flexible about the order of file operations that I mentioned above, as long as it culminates in the last three steps of it:
Set, in Filepath_2\CI_2.xlsm, a reference to Filepath_2\AI_2.xlam
... handle business in Filepath_2\CI_2.xlsm ...
Close and delete Filepath_2\CI_2.xlsm and Filepath_2\AI_2.xlam
Just one pre-emptive note to save everyone's time: Please do not suggest changes to the current suite of filepaths as the desired solution cannot interfere with the rest of what needs to be done. This file setup is part of a much larger situation that handles business in secondary copies of master files, after which the secondary copies must be closed and deleted.
This is my first question on Stack Overflow. I've attempted to make it self-contained as well as be free of actual VBA code since I don't think that someone who knows the solution I've asked for needs my own code to provide the few lines of code that most likely comprises the solution.
If you think you can help me out but need more information or some actual code, please let me know. Thanks!
Edit:
Thanks for your comments so far. Allow me to clarify further, and I think that this really gets to the crux of the matter. I've also edited my original question to correct some minor inaccuracies.
I earlier misstated one of the steps above as:
Close Filepath_1\AI_1.xlam
I don't attempt to do this anywhere.
Once I open Filepath_2\CI_2.xlsm, it has a reference to and shows the VBA project for Filepath_1\AI_1.xlam; the problem is that Excel does not, at any point, recognize Filepath_1\AI_1.xlam as an open file.
In fact, even if I open Filepath_1\AI_1.xlam by its mere self (without opening up any files that reference it), Excel does not recognize it as an open file, although it opens up the VBA project for the file. By 'recognize', I mean that if I use a For Each loop to cycle through the open add-ins (or open workbooks), Filepath_1\AI_1.xlam never shows up.
What I'm trying to do seems like it should be quite doable, and yet I just cannot find any way of doing it that doesn't leave that stray VBA project open...
I've got a really strange error and any light that anyone can shed on this would be greatly appreciated.
I made some changes to some VB6 source which builds a COM object. The automated build which builds our app returned an error. No problem I thought--I'll just back out my changes. Well backing out my changes isn't making the problem go away.
Specifically when I attempt to build the app via a .vbg file, with a command line like path\to\vb6\vb6 ProjectFile.vbg /make
I get a message
"Compile Error in File '', Line : Object library
invalid or contains references to object definitions that could not be
found."
As I said, I reverted the source code so I'm really stumped as to why this error is still occurring. Any VB6 gurus around who might be able to point me at an answer?
I can post the exact code in question but the fact that it was building correctly, stopped building correctly and now refuses to build correctly makes me think this is not a problem with my code but rather some problem in the environment. Like something got put in the registry as a result of the previous build error.
Any tips, hints, or suggestions greatly welcome. I realize my question is a bit sketchy but I'm not even sure what's important to include and what isn't.
EDIT 1:
Thanks for the excellent suggestions guys. I think it is something to do with VB6 doing some sort of auto-registration.
Just to add a bit more detail: this problem does not occur when I build the referenced vbp file from the IDE. It only happens on the make on the .vbg which contains the vbp. Also the build tool in question automatically pulls latest source and the error happens on both my local box and the dedicated build box.
EDIT 2:
Hi again all,
The release engineering fellow figured out how to get this to build in his build environment so it's currently ok. Once we're past this crunch, I'll try to interrogate him about what he did and share the details with everyone.
Thanks again for all the great suggestions. This is what's so great about SO; that is, I asked about a 10-year-old technology and I got several great and on-point ideas.
Make sure that the VBG and all the VBP's got rolled back as well. That error is consistent with a project trying to reference a CLSID that is no longer valid for the dependency. Have you tried loading up the project group and building from the IDE, if that works and you save and check in all the changes to the group and project files, you might be fixed up.
I'm guessing the fact that you mention that it was a COM component might be the source of the problem. If any of the public method's or properties have changed then I seem to remember that VB6 will change the interface GUIDs and auto register the new ones.
My suggestion would be to check the registry to look for any mention of the component name, make a note of any associated CLSIDs, back up the registry, and then delete the references.
As cmsjr mentions it could also be a bad CLSID reference in your .vbp files.
The other option is that the failure has caused a problem with some .tlb (type library) or olb (object library) files.
The best thing to do is move all your compatibility DLL to a separate and combined directory. The reason for this is control over what VB6 is using to check for binary compatibility. In addition the Typelibs that are generated IMPORT the references. So if you using Binary DLL Ver 10 for compatibility however the import is pulling in Binary DLL Ver 9 you will have issues. By keeping all the libraries in a single folder and pointing your projects to the DLLs in that folder you ensure that the respective TypeLib Import the correct version.
Finally if you have multiple levels of DLL reference each other. You may run into mysterious error where the VB6 is unable to compile using binary compatibility. In such cases you need to compile the lowest DLL in the hierarchy (Utility DLL perhaps) copy it over into the compatibility folders. Work your way up the chain until everything compiles in one shot again.
This is because if have DLL A reference DLL B which Reference DLL C. VB6 will get sometimes get confused if you make a change to A and C. will compile fine but A will not until the compatibility libraries are updated.
Hunt down and delete any .obj and .exp files that may be lying around from the previous failed build.
You will have to open the project & re-type in the lines that you changed.
Save the project alongwith VBG and re-compile after that.
I think that will fix it.
EDIT: The idea is that the cls/bas file remember the class (CLSID) that you used. So, if you change the references but don't change the lines in the cls/bas - it is a mismatch of type (what was referenced vs what is typed in cls/bas file).
I admit...I am posting this question because I still don't have an answer to my other question and thought I would take a different tact.
Can someone explain to me WHERE the values for intellisense and namespace/class/member completion works. I figured if I can drill into where/how it is deriving that data I can try to reconfigure my project so that it will resolve my namespaces correctly.
Seth
The name space and intellisense information, for the CLR, comes from a database hidden inside the VS install.
The information for the working project, is scanned and archived (I think in a file) when you open the project. It then periodically updates it as you work.
If you want the exact path, I doubt that Microsoft publishes that information.
After looking at your other question, I wanted to add that it is possible (somehow) to have Visual Studio rebuild the index information for a given project. It eludes me on how to do this right now. Have you tried this and did you end up with the same results?
Update in regards to comments:
Refreshing the cache is easy but not
necessarily obvious. There are two
ways to refresh the cache: 1) Go to
Edit -> IntelliSense -> Refresh Local
Cache and 2) Hit Ctrl+Shift+R
Source: Dan's Blog - Refreshing the IntelliSense Cache
I don't know how it's done in Visual Studio, but here is the general approach:
Collect all the public members and methods.
This is done, in case of managed libraries like those produced by VB.NET, by reflection. The documentation comes from xml files related to those libs. That's the approach for Referenced libraries.
For the project you are currently working on, it just constantly parses the source files where the documentation is combined with the code.
How the namespace resolving is done depends on the language offcourse, but that is answered in your other question.
I realize this question has been asked before, but I was not able to find anything that worked for me yet.
Things I have tried:
Switched settings back to default (mulitple ways)
Project Builds/Compiles fine
Closed VS and restarted
The only thing I haven't been able to try is deleting the ".ncb" file, but that's only because I can't find it. In fact not a single one of all our projects have such a file!
So the first question is why can't I find this file in the solution's root directory? The only file I have there besides the .sln is the .suo.
Then if that doesn't work what other options do I have short of un-installing and re-installing?
As for how it happened this might help. While using VS2008 and VSS6.0 (yuck) I made a number of changes to a lot of files via Find&Replace that I didn't mean to(had Entire Solution selected instead of current document). To undo the changes I exited without saving, reopened the solution, then Undid checkout. After that I lost intellisense! I can't imaging how they're related but it might help.
Thanks,
Jeff
IntelliSense usually stops working when it can't compile correctly. Try a new simple project from scratch and see if it works, if it does you have your answer.
Is this for C++ code? If it is, my suggestion is not to try fixing built-in IntelliSense at all, rather try some 3rd party replacement. My favourite is definitely Visual Assist X, which is lot more robust (it almost never stops working, and it is able to parse even very complicated templated and preprocessed stuff, which often makes IntelliSense "lost".
Visual Assist works with other languages including Visual Basic, however this is something I have no practical experience with. Still, there is a free trial - you may try it, I expect it will be superior to IntelliSense even for VB.
Answer:
I figured out how to fix it. Apparently while I was undoing those changes I somehow excluded the file that I wasn't getting intellisense in from the project.
I just right-clicked on it and said "Include in Project" and viola! Intellisense worked again.
Sorry for the false alarm but I appreciate the effort.
Jeff