> I just tried to do a user install with v1.21 and I don't think it's possible. The default install folder is "C:\Program Files (x86)\Rubberduck\Rubberduck" and obviously this folder requires admin. I manually changed the folder to a local user folder, but the installer still requires elevation to continue. Note the Elevation symbol on the "next" button in the screenshot. !image The...
installer may not be checking if Elevation is required, and is requesting it regardless. Or it may intend to register the classes in HKLM\Classes, which will always require Elevation. For the per-user install to work, two things need to happen: the addin .dll file is installed to a local user folder (i.e. %APPDATA%\Roaming), and the Classes are registered in HKCU\Classes. Ideally, the installer should first let the user select a Per-User or System-Wide install, and then the set the default...
install folder and class registry keys to appropriate locations.
> Okay. I wasn't 100% sure that had worked. I followed the instructions from installshield, but I must have missed something. I'll see if I can't make this happen for 1.3 instead. The bug fixes were a priority. I honestly don't understand why the classes weren't registered under HKCU. Will take a look at my test machine in the morning to see where the CLSIDs were registered.
> Classes are registered under HKCR/CLSID. I'm still working on geting a x64 installer to work, I'll try registering them under HKCU/Software/Classes/CLSID and see what I get - that's pretty much the one thing I haven't tried as of yet.. hold on......
I understood up front that an install without admin might not be possible.
I updated that comment btw. I'm wondering if it's because the original install was on the machine. Might have to totally uninstall to get a clean per user install.
> I'm also going to call out that all installs are "per user" regardless of the installer settings, required rights, or location of the CLSIDs in the reg. the add-in can only be registered for the current user. I understand that doesn't change anything here. Just something to keep in mind.
Yeah. I know. Just didn't want to lose sight of that. I honestly don't care if there's an admin free install, but for that reason, it really does make sense to have a per user install.
> > If an installation is running in maintenance mode, the InstallScript engine determines the value of the ALLUSERS variable based on whether the initial installation was installed as per-user or per-machine (based on the location of where the uninstallation information was installed). helpnet.installshield.com/installshield18helplib/mergedProjects/… Please try a clean install instead of an upgrade. (Make sure to back up your rubberduck.config file...
I didn't mean to barge in. I was asked to point Zephyr at this room to watch for close vote requests. I was just trying to figure out why. It doesn't look like you guys have any of those :)
I am a moderator of moderators. Or, I was until the name changed and that joke no longer works
1. If I write some build scripts what language would you like it to be in? Optionas are any cross platform scripting language: Python, ruby, scala, lua etc.
@RubberDuck Zephyr watches a few rooms around the network for cv-pls type messages and posts them in a single room. It shares the room with another bot used for detecting low quality stuff around the network. (I don't control that one)
Fair enough. You guys haven't used the syntax it looks for at all (unless the search function is lying to me), so it makes sense to not have it in here
> I'll look farther into it, but an admin-less install may not be possible with all the COM registration that happens. Please feel free to fork and attempt a fix if we don't get to it in a timely manner.
> @retailcoder just fyi... HKCR is not the true location where classes are registered. It mirrors the contents of other locations: The content of HKEY_CLASSES_ROOT comes from two sources: HKEY_LOCAL_MACHINE\SOFTWARE\Classes and HKEY_CURRENT_USER\SOFTWARE\Classes. If a subkey or entry appears in either location, then it also appears in HKEY_CLASSES_ROOT. If the values of entries in the two Classes subkeys conflict, then only the value in HKEY_CURRENT_USER\SOFTWARE\Classes appears in...
@ckuhn203 I appreciate you guys spending the time on this, I know it is not a high priority versus other tasks.
When I have time this week, I do plan to hack together a registry key to install this addin on my work PC, same as what I did for MZ-Tools v3. After I have it running I will show you what I did.
> Thanks @christophocles. I imagine it involves exporting the keys and creating a .reg file manually? I may be able to assist in that endeavor tomorrow if I have a few extra minutes.
> I've just experimented a bit - it seems the only keys that matter are under HKLM (excluding the add-in key itself, registered under HKCU/Software/Microsoft/VBA/VBE/6.0/Addins64). I successively removed them from everywhere I saw them and launched Excel only to see Rubberduck still alive - it only died when the HKLM keys were removed. I'm giving up on this one.
> I can confirm that in v1.21, all of the CLSIDs are registered in HKEY_CURRENT_USER\Software\Classes\Wow6432Node\CLSID. This was not the case in v1.2.
The only registry keys in HKLM are the ones related to the installer/uninstaller.
> Ok I think I scrubbed my whole registry clean - backing up, I'll give it another shot.
The Wow6432Node keys are only for 32-bit software running on x64 right? You seem to know your registry stuff, do you think this would be a working setup for a x64 build?
> @retailcoder correct. Wow6432node is used for 32-bit applications on x64 OS. So the 32-bit addin has its CLSIDs under Wow6432node, but the 64-bit addin would not. The part that actually makes the VB editor load the addin is this key (for 32-bit): HKEY_CURRENT_USER\Software\Microsoft\VBA\VBE\6.0\Addins\Rubberduck.Extension For 64-bit, it appears to be: HKEY_CURRENT_USER\Software\Microsoft\VBA\VBE\6.0\Addins64\Rubberduck.Extension So yes, I think your setup looks correct. But I don't have a...
> The one missing functionality is "Delete" - I left it out because I want to implement a "Safe delete" instead (hopefully for 1.3), so that one can't just delete a module/class/form that's actually used somewhere.
You can't pass VBA Types as arguments. (I know. I know. VBA....)
What you'll need to do is pass in/out the individual properties. Something like this (I don't know C++ so bear with me.)
void Function1(Output* Field1, Output* Field2, Output* Field3)
Option Explicit
Option Private Module
'@TestModule
Private Assert As New Rubberduck.AssertClass
Public Sub HelloWorld()
MsgBox "Hello World!"
End Sub
'@TestMethod
Public Sub TestHelloWorld()
Dim thunk As Delegate
Set thunk = Delegate.Create(AddressOf HelloWorld)
thunk.Run
End Sub
Option Explicit
Option Private Module
'@TestModule
Private Assert As New Rubberduck.AssertClass
Private globalVar As String
Private Const HELLO_WORLD As String = "Hello, World!"
Public Sub HelloWorld()
globalVar = HELLO_WORLD
End Sub
'@TestMethod
Public Sub TestHelloWorld()
globalVar = "GoodBye, World!"
Assert.AreEqual "GoodBye, World!", globalVar, "Initialization"
Dim thunk As Delegate
Set thunk = Delegate.Create(AddressOf HelloWorld)
thunk.Run
Assert.AreEqual HELLO_WORLD, globalVar, "Value changed"
> Hey team -- argh, another Office 2013 x64 issue! After a fresh install (via Rubberduck.v1.21.Setup.x64.exe) following all the defaults (%HOMEPATH%\AppData\Roaming\Rubberduck.Install install path), I get an error message indicating that the Rubberduck add-in could not be loaded after opening the VBE from Excel: !image If it would be helpful, I can provide the installer log file. I'm...
> It might be @danwagnerco. It could at least help us figure out if it's an issue with 2013 or x64. Both are a bit suspect at the moment, but the x64 installer was tested on 2010 I believe.
> Consider the following standard code module: Option Explicit Private Sub Test1() Debug.Print Forms("MainMenu").Name End Sub Private Sub Test2() Debug.Print Forms!MainMenu.Name End Sub Private Sub Test3() End Sub This module will be displayed in Code Explorer as such: - Module1 Test1 Test2 Note that Test3 is not shown in Code Explorer. Double-clicking on Test2 in Code Explorer highlights the following text only: Private Sub Test2() D
> When right clicking on an item in the Code Explorer, it would be great to have a "Rename" option. Not only does this move us toward removing the need to ever open the built in Project Explorer, but it also would mean there's almost never a need to open up the Properties view.
> Renaming a module, class, or procedure/function, needs to have cascading effects on the entire code base - these effects are globally referred to as a "rename refactoring".
> Hey buddies -- I don't know ANYTHING about C#, but I would be happy to test builds for y'all. I have access to Office 2013 on Windows 7 (at work) and Windows 8.1 (at home).
You can't pass VBA Types as arguments. (I know. I know. VBA....)
What you'll need to do is pass in/out the individual properties. Something like this (I don't know C++ so bear with me.)
void Function1(Output* Field1, Output* Field2, Output* Field3)
VBA Rubberducking
VBA Rubberducking