<div dir="ltr">Thanks Ken. Makes sense. </div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 21, 2023 at 5:41 PM <<a href="mailto:ken.dickey@whidbey.com">ken.dickey@whidbey.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2023-03-21 12:57, Alexandre Rousseau via Cuis-dev wrote: > My point was the system complained that "MyTheme beCurrent " , scripted > after the loading of said packaged theme, was pointing to a non > existent class ... i.e., the loading was not complete when the > "beCurrent" message was sent. Which makes the loading of packages > asynchronous, does it not? Actually, not. It is a processing time problem. The code is first compiled as _a block_ and when that happens #ClassicTheme is undefined, so nil. If you initially type Feature require: #'Theme-Themes'. ClassicTheme beCurrent. into a workspace, you will see #ClassicTheme in RED because it is yet undefined. If you select both lines and DoIt, you will get the #ClassicTheme undefined exception, but if you select the first line and DoIt, then you will note #ClassicTheme has turned BLUE as it is now defined. You can select the 2nd line and DoIt, AOK. Since you are sending a block of text to be compiled at one time, you have to deal with undefined values _at the time the text is compiled_. The easy fix in this case is to compile-in the explicit code to do the lookup: Feature require: #'Theme-Themes'. (Smalltalk at: #ClassicTheme) beCurrent. Note that I do not find this very intuitive either. HTH, -KenD </blockquote></div>