SOLVED
Home

Add-in registry access problem

%3CLINGO-SUB%20id%3D%22lingo-sub-299525%22%20slang%3D%22en-US%22%3EAdd-in%20registry%20access%20problem%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-299525%22%20slang%3D%22en-US%22%3E%3CP%3EI%20am%20the%20author%20of%20an%20add-in%20(Rainbow%20Analyst)%20which%20retrieves%20certain%20stored%20user%20details%20from%20the%20Windows%20Registry%20during%20startup.%20This%20code%20has%20operated%20without%20any%20problem%20for%20some%20years%20now%2C%20but%20following%20the%20latest%20(November%202018)%20update%20to%20Windows%2010%201803%20and%2For%20Office%20365%20(64-bit%20version)%2C%20when%20I%20click%20an%20existing%20(i.e.%20Recent)%20Excel%20workbook%20in%20the%20Excel%20startup%20screen%2C%20Excel%20silently%20crashes%20(closes)%20before%20displaying%20the%20add-in.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20have%20traced%20the%20crash%20to%20the%20code%20which%20accesses%20the%20Registry%2C%20because%20although%20the%20crash%20occurs%20some%20time%20after%20this%20code%20is%20executed%2C%20it%20seems%20(from%20experiment)%20that%20it%20can%20only%20be%20prevented%20by%20eliminating%20this%20section%20of%20code%20(not%20feasible%20in%20practice%2C%20as%20essential%20user%20details%20are%20stored%20in%20the%20Registry).%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThere%20is%20no%20problem%20if%20I%20click%20%22Blank%20workbook%22%20and%20then%20subsequently%20open%20an%20existing%20workbook%2C%20and%20I%20have%20also%20ascertained%20that%20the%20crash%20only%20occurs%20when%20the%20Registry%20is%20accessed%20more%20than%20once%3B%20it%20can%20be%20avoided%20if%20I%20modify%20the%20code%20to%20limit%20it%20to%20a%20single%20Registry%20access%20(not%20feasible%20in%20practice).%20I%20currently%20use%20the%20VBA%20GetSetting%20function%2C%20but%20the%20same%20problem%20occurs%20if%20I%20create%20a%20WScript.Shell%20object%20and%20use%20the%20RegRead%20method.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20am%20new%20here%2C%20so%20I%20hope%20this%20is%20the%20correct%20place%20to%20raise%20this%20problem.%20Any%20suggestions%20will%20be%20much%20appreciated!%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-299525%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EMacros%20and%20VBA%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-299671%22%20slang%3D%22en-US%22%3ERe%3A%20Add-in%20registry%20access%20problem%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-299671%22%20slang%3D%22en-US%22%3EYou're%20welcome.%20I%20have%20fixed%20issues%20like%20these%20using%20this%20technique%20in%20quite%20some%20of%20my%20add-ins%20as%20available%20through%20%3CA%20href%3D%22https%3A%2F%2Fjkp-ads.com%2Fdownload.asp%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fjkp-ads.com%2Fdownload.asp%3C%2FA%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-299664%22%20slang%3D%22en-US%22%3ERe%3A%20Add-in%20registry%20access%20problem%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-299664%22%20slang%3D%22en-US%22%3EExcellent%3B%20this%20has%20solved%20the%20problem!%20I've%20set%20all%20custom%20tabs%20as%20initially%20invisible%2C%20then%20run%20the%20rest%20of%20the%20start-up%20code%20after%20one%20second%20and%20refreshed%20the%20ribbon%20(with%20.Invalidate)%2C%20and%20all%20works%20fine.%20Many%20thanks%20again%20for%20your%20help.%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-299589%22%20slang%3D%22en-US%22%3ERe%3A%20Add-in%20registry%20access%20problem%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-299589%22%20slang%3D%22en-US%22%3EMany%20thanks%20Jan%20Karel%20for%20this%20prompt%20and%20helpful%20response%3B%20much%20appreciated%2C%20and%20I'll%20certainly%20give%20this%20a%20go.%20There's%20a%20slight%20potential%20issue%20because%20the%20add-in%20uses%20the%20registry%20reads%20to%20determine%20what%20tab%20or%20icon%20to%20display%20on%20the%20Ribbon%20(using%20the%20isVisible%20property%20of%20the%20IRibbonControl%20objects)%2C%20but%20I%20guess%20it%20shouldn't%20be%20a%20problem%20to%20delay%20the%20Ribbon%20display%20by%20a%20fraction%20of%20a%20second.%20I'll%20try%20it%20and%20post%20again%20to%20confirm%20the%20outcome.%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-299563%22%20slang%3D%22en-US%22%3ERe%3A%20Add-in%20registry%20access%20problem%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-299563%22%20slang%3D%22en-US%22%3EDoes%20it%20help%20to%20postpone%20the%20registry%20reads%20until%20Excxel%20has%20really%20fininshed%20starting%20up%3F%20What%20I%20usually%20do%20to%20allow%20Excel%20to%20finish%20it's%20business%20during%20startup%20is%20(in%20Workbook_Open)%20schedule%20a%20macro%20called%20%22ContinueOpen%22%20situated%20in%20a%20normal%20module%20using%20Application.Ontime.%20This%20prevents%20all%20sorts%20of%20issues%20stemming%20from%20Excel%20not%20having%20finished%20to%20load%20completely%20when%20your%20Workbook_Open%20is%20called.%3C%2FLINGO-BODY%3E
mike_s
New Contributor

I am the author of an add-in (Rainbow Analyst) which retrieves certain stored user details from the Windows Registry during startup. This code has operated without any problem for some years now, but following the latest (November 2018) update to Windows 10 1803 and/or Office 365 (64-bit version), when I click an existing (i.e. Recent) Excel workbook in the Excel startup screen, Excel silently crashes (closes) before displaying the add-in.

 

I have traced the crash to the code which accesses the Registry, because although the crash occurs some time after this code is executed, it seems (from experiment) that it can only be prevented by eliminating this section of code (not feasible in practice, as essential user details are stored in the Registry).

 

There is no problem if I click "Blank workbook" and then subsequently open an existing workbook, and I have also ascertained that the crash only occurs when the Registry is accessed more than once; it can be avoided if I modify the code to limit it to a single Registry access (not feasible in practice). I currently use the VBA GetSetting function, but the same problem occurs if I create a WScript.Shell object and use the RegRead method.

 

I am new here, so I hope this is the correct place to raise this problem. Any suggestions will be much appreciated!

4 Replies
Solution
Does it help to postpone the registry reads until Excxel has really fininshed starting up? What I usually do to allow Excel to finish it's business during startup is (in Workbook_Open) schedule a macro called "ContinueOpen" situated in a normal module using Application.Ontime. This prevents all sorts of issues stemming from Excel not having finished to load completely when your Workbook_Open is called.
Many thanks Jan Karel for this prompt and helpful response; much appreciated, and I'll certainly give this a go. There's a slight potential issue because the add-in uses the registry reads to determine what tab or icon to display on the Ribbon (using the isVisible property of the IRibbonControl objects), but I guess it shouldn't be a problem to delay the Ribbon display by a fraction of a second. I'll try it and post again to confirm the outcome.
Excellent; this has solved the problem! I've set all custom tabs as initially invisible, then run the rest of the start-up code after one second and refreshed the ribbon (with .Invalidate), and all works fine. Many thanks again for your help.
You're welcome. I have fixed issues like these using this technique in quite some of my add-ins as available through https://jkp-ads.com/download.asp
Related Conversations
Tabs and Dark Mode
cjc2112 in Discussions on
46 Replies
Security Community Webinars
Valon_Kolica in Security, Privacy & Compliance on
13 Replies
flashing a white screen while open new tab
Deleted in Discussions on
14 Replies
Extentions Synchronization
Deleted in Discussions on
3 Replies
Stable version of Edge insider browser
HotCakeX in Discussions on
35 Replies