ini file: ” _ & Err.LastDllError DeleteIniSection = False LogError “DeleteIniSection”, Err.Number, Err.Description End If If WritePrivateProfileString(StrSection, vbNullString, _ vbNullString, LpFileName) Then DeleteIniSection = True Else MsgBox “Error deleting section from. ‘ Function DeleteIniFileSection( _ StrSection As String, _ LpFileName As String _ ) As Boolean ini file: ” & Err.LastDllError WritetoIniFile = False LogError “WriteToFile”, Err.Number, Err.Description End If If WritePrivateProfileString(StrSection, _ StrKey, StrValue, LpFileName) Then WritetoIniFile = True Else MsgBox “Error Saving to. ‘įunction WritetoIniFile( _ ByVal LpFileName As String, _ ByVal StrSection As String, _ ByVal StrKey As String, _ ByVal StrValue As String _ ) As Long ‘ Declare Function GetPrivateProfileString Lib “kernel32” _ Alias “GetPrivateProfileStringA” _ (ByVal lpApplicationName As String, _ ByVal lpKeyName As Any, _ ByVal lpDefault As String, _ ByVal lpReturnedString As String, _ ByVal nSize As Long, _ ByVal LpFileName As String) As Long ‘ Declare Function WritePrivateProfileString Lib “kernel32” _ Alias “WritePrivateProfileStringA” _ (ByVal lpApplicationName As String, _ ByVal lpKeyName As String, _ ByVal LPStringName As String, _ ByVal LpFileName As String) As Long Public LpFileName As String ‘this global contains the name of the INI file assigned to this application
here is my code for the ini file and connection string: IU store the dblocation in an inifile along with any setting I want to remeber. Place" interface-wise, but seems the best for AddIns and we have learned a big lesson there to check those much more tightly.Personally I always avoid this through error control. I dont really like how that is kind of "all over the We are long-time InstallAware users - although on these two AddIns (as we have done on a couple others) we went with the Visual Studio Installer Project. Thanks for the link to the article - no, that was not the one I was mentioning, but it is some good useful information so we're bookmarking that. Installs to match for both the Excel and Word versions and now both load fine - so far we have tested them on XP and Win7 and they both load and run fine.
As it turns out, the Word AddIn install DID NOT have the registry write or Launch Conditions and once these were fixed, I also checked through for all references to the proper version of. Now that we know its the registry values, at least I can get the QA guys up and testing what the Addin is intended to do - we will keep working through the other issues. One question: We found a doc on the Web that says Office Addins dont write their registry values during Install.
We are working to correct these differences now, and then will
And #2, Although we have the Advanced Compile Options set to. These were done largely identically (or so I thought) and yet we have noticed two problems with the Word version: #1 There are no Launch conditions for the Word version, whereas there are for theĮxcel version. This led us to review the installs for both AddIns. And when I added the regkeys manually (to Office\Addins.) Bingo! The Addin goes through its first time "Verify Publisher" and Well, we've had a bit of a breakthough - we found that though the Excel Addin is registering, the Word one IS NOT. Thank you in advance for any answers, suggestions or comments. Two so similar AddIns have ONE work, the OTHER doesnt?
The Word AddIn WILL NOT install on any machine other than Windows 7 / Office 2010. The Excel AddIn installs perfectly on any BOTH of these AddIns install perfectly on every These were developed in Visual Studio 2010 and VSTO. I have two AddIns that are extremely similar - one goes for Excel, one goes for Word.