[Rd] Private environments and/or assignInMyNamespace

[Milan Bouchet-Valat]

Le mardi 12 février 2013 à 14:45 +0100, Ulrike Grömping a écrit :
> Dear DevelopeRs,
> 
> I've been struggling with the new regulations regarding modifications to 
> the search path, regarding my Rcmdr plugin package RcmdrPlugin.DoE. John 
> Fox made Rcmdr comply with the new policy by removing the environment 
> RcmdrEnv from the search path. For the time being, he developed an 
> option that allows users to put the environment from Rcmdr (RcmdrEnv) on 
> the search path, like in earlier versions of Rcmdr (thanks John!), which 
> rescues my package for the immediate future; however, in the long run it 
> would be nice to be able to make it work without that.
> 
> The reason why I currently need the environment on the search path (may 
> be due to my lack of understanding how tcltk widgets are handled): I 
> have quite elaborate notebook widgets on which users can make many 
> entries. Some entries are only checked after clicking OK, and if an 
> error is found at that point, the user receives a small message window 
> that has to be confirmed and is subsequently returned to the notebook 
> widget in the state it was in when pressing OK. These widgets are 
> currently held in the environment RcmdrEnv; they work when RcmdrEnv is 
> on the search path; however, it is not sufficient to retrieve them with 
> John's function getRcmdr, which works fine for objects other than widgets.
I'm not sure I understand exactly how this works, but does that mean you
close the dialog before checking the entries? If it is the case, you
could check them before, and if an error is detected, you would keep the
dialog open: this way, you would not need to restore anything.

Could you point us at the relevant code?


Regards

> Here my question: Would it be an option to place the widgets in a 
> private environment of my plugin package (then I would have to learn how 
> to create one and work with it), or won't they be found that way? 
> Alternatively, I could have unexported objects of all required names in 
> my namespace and modify these via assignInMyNamespace (I don't think 
> that anybody from somewhere else would import that namespace, it's not 
> that kind of package). Would that be a viable alternative, and would the 
> widgets be found that way? Any further ideas?
> 
> Best regards,
> Ulrike
>