I have an access-vba application that also makes use of word-vba. While running the application on my local machine, it functions well. Once it is moved to others (same versions of access and word) it will crash when it comes to the vba portion of word. Commands such as document.open or .saveas2 fail: Method 'SaveAs2' of object failed for example.
I've also noticed that libraries that I've referenced in the application are required by any other end user. I'm used to just compiling with the libraries and from that point they are always included in the .jar/.exe/etc, but, it seems when you move the application to other's computers it's always trying to recompile?
I'm not well versed in VBA so I'm speculating that my failing word-vba functions are because of a referencing error, any other ideas?
The "libraries" that VBA can reference are actually COM objects, usually packaged as DLL files. They are objects which are dynamically instantiated at runtime (if they aren't already) when requested. They are loaded by Windows into memory and your program uses the COM standard to interact with them, calling methods and getting or setting properties (interprocess communication). There are generally two ways of interacting with them: early binding and late binding.
With early binding, you add a reference to the library while you are still writing code, which allows the VBA IDE to provide autocompletion and some compile-time error checking. You instantiate objects with the "new" keyword and by directly typing the object name. However, early binding requires that you select a specific dll and possibly a specific version of the interface. This can lead to issues if you reference a specific interface version which one of your users doesn't have.
With late binding, you instantiate objects using CreateObject or GetObject, requesting them by name from Windows. Windows will look the name up and return a reference to the object. The variables in your code are simply objects and calling methods is a bit dangerous because the compiler allows you to type in whatever method name you want and provides no compile-time warnings. This has the advantage that as long as you are calling well established methods and nothing new or deprecated, the code will work regardless of the user's version.
As for the error you are getting, you may want to check the version of Office on the user machines - SaveAs2 was added in Office 2010.
Related
I started playing around with Haxe recently, after using AS3 for quite some time and ran into a problem while writing a very simple game engine:
I have a class called World. One of the things the World does, is keeping track of all Entity objects in the game. I want this list of Entity objects to be accessible ONLY from within the engine. The user of the engine should not be able to modify the list directly.
In AS3, I could simply use the internal keyword to give access to other classes within the same package. And when that wasn't enough I could define a custom namespace and use it as my access modifier. But Haxe doesn't seem to have either of those.
TL;DR: How can I restrict access of a variable to a specific package/namespace? If not possible, what other options do I have?
If you're using Haxe 2.11 (nightly build), you can use #:allow.
Copied from the Haxe.org wiki:
#:allow(my.pack) : This will give access to all private fields of a
class to all the classes in the package my.pack (and its
sub-packages). See Access Control for more info. (since 2.11)
More detailed doc on Access Control.
I've often heard about "handles", what exactly are those?
Edit:
For instance I have heard about:
windows handles
event handles
file handles
and so on. Are those things the same? Or they are some abstract terms?
A handle is an indirect way to reference an object owned by the OS or a library. When the operating system or a library owns an object but wants to let a client refer to it, it can provide a reference to that object called a handle.
Handles can be implemented in different ways. Typically they are not references in the C++ or C# sense. Often they are pointers cast to some opaque type, or they might be (or contain) an index into a table of objects that are owned by the operating system or library.
For example, in Windows, if you create a window, the OS creates an object that represents the window, but it doesn't return a pointer to that object. Instead, it returns a window handle, which provides an extra layer of indirection. When you pass the window handle back in another OS call, the OS knows which window object to use based on the handle. This prevents your code from directly accessing the window object.
The extra layer of indirection allows the OS or library to do things like move objects around, reference count the objects, and generally control what happens to the object. Like the PIMPL idiom, the implementation may change completely while still preserving the original API and thus not forcing clients to recompile. It's especially useful if you're trying to offer a non-object-oriented API for clients written in procedural languages like C.
A "handle" is another name for a reference to a resource which is managed by the programmer explicitly instead of automatically by the runtime.
Handles are pointers to unmanaged resources like file handles, database connection handles, windows handles, etc... As they are handles to unmanaged resources in most cases they won't be automatically garbage collected and you need to ensure to properly release them or you might hear about leaking handles.
Here is my problem:
I have two C++ modules, A and B, which are built as dynamically-linked libraries. A offers basic math functions, and custom exception types. B is a higher level module that uses A.
B::someFunction() calls a function from A, and tries to catch custom exception A:MyExceptionFromA in order to convert it into a custom type B:MyExceptionFromB (since users of module B do not need to know about the implementation details of A).
Everything works fine as long as I remain in the C++ domain. However, if I expose B::someFunction() in python via boost python, the exception is not caught anymore in the C++ module.
I can catch std::runtime_error, from which A:MyExceptionFromA derives, and call typeid(e).name() to get the retrieve the correct mangled name, so I know the correct exception is thrown. Therefore I suspect that the problem comes from resolving this mangled symbol into the correct exception type.
I have found this link, which explains that "python uses [the insular] model to open extension modules, so that extension module writers don't need to know what symbols other extension modules might be using.". I'm suspecting this is part of the problem/solution, but I do not know enough about symbol resolution to figure out how to solve my problem.
Any ideas?
I found a work-around to my problem. Based on this and link text, I figured out that adding
import sys, dl
sys.setdlopenflags(dl.RTLD_NOW|dl.RTLD_GLOBAL)
before my includes solves the problem, by forcing python to open libraries in immediate, global mode. But I'm still hoping for an alternative solution, if there's one. As mentioned in the first link, I'm suspicious that this could have unforeseen effects (I already know that name clashing could be a problem, and I suspect performance can be affected as well, but are there other side effects?)
I am working on a custom data transformation component. I'm using NUnit and NMock2 to test as I code. Testing and getting the custom UI and other features right is a huge pain, in part because I can't find any documentation about the order in which SSIS invokes methods on the component at design time as well as runtime.
I can correct the issues readily enough, but it's tedious and time consuming to unregister the old version, register the new version, fire up the test ssis package, try to display the UI, get an obscure error message, backtrace it, modify the component and continue.
One of the big issues involves the UI component needing access to the componentmetadata and buffermanager properties of the component at design time, and what I need to provide for to support properties that won't be initialized until after the user enters them in the UI.
I can work through it; but if someone knows of some docs or tips that would speed me up, I'd greatly appreciate it. The samples I've found havn't been much use; they seem to be directed to showing off cool stuff (Twitter, weather.com) rather than actual work.
Thanks in advance.
Here's a timeline of the run-time execution sequence: Run-time Methods of a Data Flow Component
The design-time sequence isn't laid out in MSDN that nicely because there just isn't such a sequence, but here's what I think/know:
1. ProvideComponentProperties - called ONCE EVER when the component is dropped on the design surface.
2. PerformUpgrade - called ONLY if the metadata version is different than the version attribute on the class - called on package load.
3. Validate - called FREQUENTLY... during package load, input attachment, entry into editor, etc...
4. ReinitializeMetaData - called infrequently, and only because a VS_NEEDSNEWMETADATA value is returned from Validate.
Everything other override (OnInputAttached, etc.) is fairly straightforward as to when it gets called. Here's the not-so-descriptive article: Design-time Methods of a Data Flow Component.
I have a Access ADP Project that has been a continus project for the last 6 years, so it has hundreds of forms and thosands line of VBA code. After a recent update it not wont compile to create the ADE file. It tells me one of the text boxes does not exist but it does. I deleted the for and re imported it from a working backup and still the same error. I have tryed Importing the whole project into a new ADP file and still wont compile, tryed compact and repair and also /decompile
Does anyone no of any tricks or software package to help fix this problem?
I don't work with ADPs, but in MDBs, there are differences between these two syntaxes for referring to controls on a form:
Me.MyControl
Me!MyControl
The first causes Access to create a hidden property that returns the control. The result of this is compile-time checking of references to controls.
The second uses the default collection of the current form and does not provide compile-time checking.
I assume that VBA works the same in ADPs as in MDBs, so why not try converting the offending control references to bang instead of dot? This would eliminate the compile-time checking and might allow the project to compile without having to reconstruct it laboriously.
If that works, I think I would then try deleting the control (to removed the hidden property definition) and add the control back with a new name and then compact (I don't know if ADPs can be decompiled, but if they can, it should be decompiled as well). Theoretically, this should remove the problematic hidden property definition permanently and if that's the cause of the problem, you should be able to revert to the dot operator and get compile-time checking back.
For what it's worth, I've seen too many corruption problems with the dot operator and always use the bang in all my projects. I'm OK with not having compile-time checking of control references.
And, oh, BTW, with the bang you lose automatic Intellisense (which in some cases is a blessing as Intellisense can get in your way in some contexts), but you can invoke a different Intellisense list with CTRL-SPACE. This list is not limited to the control type, but once you start typing, you get the usual autocomplete that jumps you to the appropriate location in the list.
Sometimes it helps to start a new, empty project and then import all forms/reports/modules from the old one.
If birger's approach doesn't do the trick, consider saving each module using the SaveAsText method. Then, as birger suggested, import, but ONLY the forms, and tables. Then, recreate the modules, using the LoadFromText method.
Sometimes, I found out that I need to manual click Debug -> Compile before making ADE files.
This following steps may help for unable-compile ADP file:
Debug -> Compile
Compact/Repair
then make ADE