I was using Hyperion version 9.3.3 to process my queries and was recently upgraded to version 11. The problem I'm encountering is that version 11 doesn't have the same amount to computational space as 9.3.3, so until I create a solution to this I'd like to continue to use 9.3.3 (which is still on my machine along with version 11). Does anyone know how I would do this in macros created in Excel vba? My current code is quite simple:
Set mybrio = CreateObject("BrioQuery.Application")
mybrio.Documents.Open (excel_loc & "\" & brio_filename)
This code opens version 11 though by default and I want version 9.3.3. Can anyone help me alter this code to have specifically target 9.3.3?
In VBA IDE window- Tool-->Reference --There will be the list of Visual Basic Applications. Check if there are two versions available in it? if so Uncheck the latest version and check the old version
Related
My simulation is run in the dum kinetics module, the code was written in vb automation in Visual studio 2010 environment. My problem is when I ran the simulation in Catia R18, the process was completely smooth and successful, but when I tried to run it in a different version, like R20 or R21, an error occurs.
Through the breakpoint, I found out that the error was caused by the failure of acquiring the "Mechanisms" in the product of Catia. Here is the code :
theMechanism = product1.GetTechnologialObject("Mechanisms")
When the breakpoint executes this sentence, variable theMechanism shows "Nothing".
The only way I know to solve this problem is run the code again in visual studio 2012 environment, then the simulation works in Catia R20 or R21, but after that you can't run the simulation in Catia R18, if you want to revert back to the version R18, you have to run the code in visual studio 2010.
Can anyone explain what is the cause of the conflict between versions of Catia and give me a solution for this? Thanks!
I think You have defined theMechanism as Mechanism Instead try it as variant.
product1.GetTechnologialObject("Mechanisms")
Returns Mechanisms, not Mechanism.
So:
theMechanisms = product1.GetTechnologialObject("Mechanisms")
theMechanism = theMechanisms.Item(1)
Also, if you have multiple CATIA versions installed on one PC, check which one is the main one (check RegServer command). Check if Visual Studio versions have references to the same CATIA version or not. In theory, they should, if you didn't change the main CATIA version.
You could also get the mechanism through the following:
KinematicsWorkbench kinWork = (KinematicsWorkbench)productDocument1.GetWorkbench("KinematicsWorkbench");
Mechanisms mechanisms = kinWork.Mechanisms;
Mechanism mechanism = mechanisms.Item(1);
This is C# code, but the VB.NET code should be nearly identical outside of some slight syntactical differences.
EDIT:
If multiple CATIA versions are installed on one machine, the last one which is installed will be a default one. To change a default CATIA version, follow these points (taken from here):
Open cmd.exe
Change Directory in the CMD window by typing “CD /code/bin” (Typically CD C:\Program Files\Dassault
Systemes\Bxx\win_b64\code\bin) and then press Enter.
In the next line type in “CNEXT.exe /regserver” and press Enter.
This will appear to have done nothing but will display the next line. At this stage restart the machine and then enjoy.
I have the below code to create an instance of Visio from Excel. It works on machines where I have a single version of Visio installed, but on some machines I have 2 versions (2010 and 2016) installed. On these machines it fails to run with the error "Method 'Visible' of object 'IVApplication' failed". When I check AppVisio its empty, and I am guessing it is because both applications are visio.exe. Is there a way to create the object from a specific path, or any way to createobject when 2 versions are installed?
Set AppVisio = CreateObject("visio.application")
AppVisio.Visible = False
Set docsObj = AppVisio.Documents
There are some options I believe.
Solution 1 (I would recommend this one). Install only Visio 2010 on your development machine (and uninstall 2016). It's safest to have the lowest version you want your app to run with on your dev machine anyways. Add a reference to Visio 2010's type library in Excel. Remove the reference to Visio 21016 type library. Visio versions are upward-compatible, so the code should run properly even on the machine with Visio 2016.
Solution 2. Use late binding. Remove the reference to the Visio from your excel project altogether and use only script-like access. In this case, you will lose auto-completion though. If your app is not a big one, that should not be an issue.
Solution 3. (if you want to run a specific version). You can start the Visio application from the program files (like any other executable), and then connect to it using "GetObject(...)" instead of "CreateObject(...)"
BTW, there is a better way to run Visio as invisible app (without flashing):
Set appVisio = CreateObject("Visio.InvisibleApp")
If you early-bind it by adding a reference (Tools | References) to the desired version then Diming your object as that type, you'll be guaranteed which version you're using.
Dim visioApplication as Visio.Application
Set visioApplication = new Visio.Application
However, that may not be the full solution if your company is mid-upgrade and some folks have the new version and some the older version. You'd get run-time issues on the machines that don't have your chosen version.
To solve that issue, you could create MyApp2010 and MyApp2016, each linking to the appropriate version of Visio, but that becomes a bit of a maintenance nightmare for you...
Early-binding does add loads of benefits like IntelliSense and turning most run-time errors into compile-time errors, so it's probably still worth it.
Recently I noticed in my current vb.net project that sometimes (depending on the value), if I enter a double value the editor changes my input, for example:
When I type ...
Dim x As Double = 0.6
...after commiting the line by pressing Enter it becomes:
Dim x As Double = 0.59999999999999998
If I directly undo the action, then it gets reverted back to the original value I typed in. Any future edit in that line will again produce the undesired results.
I'm aware that internally 0.6 is calculated as 0.59999999999999998 so it doesn't make a difference for the running application, but it's very annoying and the strange thing is: this hasn't always happened and, if I create a new project, it doesn't happen there either.
So my questions are: How can I prevent VS from doing this? Why does it happen at all? Why isn't it always like this (previously in my current project or in a new one)?
I'm running 64bit-Windows 8.1 on an Intel CPU - if that has anything to do with it.
Has anyone got any ideas?
EDIT: I'm using Visual Studio 2013 Professional (12.0.31101.00 Update 4) and, yes, the project has been migrated from several earlier VS versions. There are no relevant Add-Ins or extensions installed. Disabling "Pretty Listing" does indeed prevent the problem, but of course then the other highly useful aspects of the option are disabled as well :o(
EDIT2: After the tip leading to "Pretty Listing" I found the following SO article, but there also no solution was found: Visual Studio VB pretty listing settings
Several years ago I had a project where this was happening. As you wrote, the reason for the number is that some numbers can't be represented exactly in a binary floating point variable. More on this here.
My project had been upgraded through several versions of Visual Studio. It was also shared with developers using VS Express.
If I ran into this problem again today I would open and check the project-file manually, or just simply create a new project and re-add the files if I could not quickly locate the problem and the project was small enough.
If you have upgraded the project through multiple versions of Visual Studio like I had, it might be dragging some settings along that are no longer visible in the projects options dialog.
Just as an interesting experiment you could also try to turn off Visual Studio's Pretty Listings to see if that is what is actually changing your code.
Some months ago I installed Lazarus 0.9.28 + FPC 2.2.4 to work on a new project. Some time after it I ran into some bugs related with image loading on a TImage. After googling a bit I found some information pointing to the fact that the bugs I was facing were already solved in a later version of FPC (can't remember the link now).
So I decided to download and install a newer version. This was around January and the latest stable version was not released yet, so I choose to install the snapshot Lazarus 0.9.31-29128 + FPC 2.4.2-2011-01-20. I opened my project with the new IDE and compiled it.
Luckily the bugs I faced were gone, but I have run into an IDE (?) one. After the upgrade, when I am on the code tab of some of my forms I do not see the code formatted. Instead I only see plain text, like this:
But on some forms I see the code formatted correctly, like this:
Anyone has run into this before? If yes, could you solve it and how? Or can anyone tell me what the correct way to upgrade a Lazarus project between versions is?
It is more of a nuisance than a real problem but still I would like to solve it. Any help would be appreciated.
EDIT
I noticed that in the forms where the code shows correctly highlighted the LCLVersion in the .lfm file is 0.9.28.2, while in the forms where the code shows like plain text that property in the .lfm file is 0.9.31. Could have something to do with the problem? I tried changing the value but it did not change anything.
Thanks in advance and best regards
I don't know if this is actually causing your problem, but Lazarus keeps a set of settings in application local. ($user\AppData\Local\lazarus on my vista).
This config dir is not erased upon deinstallation, and the new installation will reuse this.
In case of strange problems, remove the config dir, and let the current installation generate a new one.
Where I'm at the developers have been updated to Excel 2007, but most of the users haven't. I'm building a spreadsheet template (*.xlt) for a user that's gonna need some vba code included, and I'm wondering what issues I'm likely to run into building this in 2007 instead of 2003? I don't have access to a machine with Excel 2003 for testing, and I'm worried this particular project is headed for disaster.
The VBA language hasn't changed, but there are additional objects in Office 2007 that are not in Office 2003. Naturally, this will cause a runtime error when you try to access these items in a 2003 environment. What's stopping you from setting about a virtual machine with Excel 2003 to develop under?
Rather than depending on a probably incomplete list of objects and methods which have been added to Excel 2007's object library, the best (mmost relliable) practice is to always develop in the oldest version of Excel likely to be used to run the code.
One difference I discovered is that a subroutine must have a different signature to be called from a menu (in Excel 2003) than when called from the ribbon (in Excel 2007). Whatsmore, Excel 2003 doesn't recognise IRibbonControl and throws compile errors.
To work toward cross-version compatability, I use a Conditional Compilation Argument and then check that in pre-processor macros.
e.g.
#If USINGRIBBON Then
Public Sub CallFromRibbon(control As IRibbonControl)
#Else
Public Sub CallFromRibbon()
#End If
' Code here
End Sub
This does mean that you have to save one version of your add-in with the USINGRIBBON flag set to false (for Excel2003) and another with the USINGRIBBON flag set to true (for Excel2007), but this is far easier than maintaining two completely separate codebases.
billb2112 is right. There are numerous changes to Excel 2007 over excel 2003 that are not backward compatible. While the language might not have changed, the objects have been updated. Some have had additional properties added, some work differently and some functions in Excel have changed.
You need to be very careful that what you code works in Excel 2003.
I would suggest as billb2112 said that you get a virtual machine to not only test in but also to code in. I do all my Excel development for clients who only have 2003 in a 2003 machine. Note that if users have Excel 2002 or 2000 there are even more differences as you go back and you will simply get runtime errors on any code that these older versions don't support.
update
unfortunately jeffs answer is not quite correct. while yes the vba language hasn't been updated it is not the same in 2007 as in 2003. as in 2003 its not the same as in 2002 etc.
what has happened is extra and additional functions and arguments for functions have been added. for example there are more options in the FIND function in Excel in 2003 than in 2002. thus if you record a macro (the best way to find these problems) in 2003 and then run it in 2002 you will have run time errors relating to the new arguments that simply do not work in the 2002 VBA editor. following the same process for functions that have changed in excel 2007 and then going back to 2003 to test will help you locate these problems. some examples include conditional formatting, colours (themes) and numerous new spreadsheet functions.
jon peltier has the best advice from that regard - develop in the oldest possible version that the client /user will use.
Virtual PC 2007 is free to download and install. you will just need a licensed copy of XP/Vista and office to install to run in it.
i used to develop a lot of macros under 2003, what a POTA,, things like Find, Dir and some others are not available or something change. therefore some erros can be expected, i used to count from 65000 row to the first non empty row to count the rows to work on.... now more rows means more work to do