[Rd] Private environments and/or assignInMyNamespace

[Ulrike Grömping]

Milan,

I am not closing the dialog, but without the dialog in the search space, 
I cannot properly refer to it any more using e.g. the Rcmdr function 
errorCondition.
It has been a long time ago that I wrote this; I don't have a small 
reproducible example right now. Below is an example of what I do in 
function Menu.pb2level:

I am using function justDoItDoE (instead of Rcmdr justDoIt, because 
justDoIt puts the focus in the wrong place for my purpose; have to adapt 
to RStudio here!):
justDoItDoE <- function (command)
{
     Message()
     if (!getRcmdr("suppress.X11.warnings")) {
         messages.connection <- file(open = "w+")
         sink(messages.connection, type = "message")
         on.exit({
             sink(type = "message")
             close(messages.connection)
         })
     }
     else messages.connection <- getRcmdr("messages.connection")
     result <- try(eval(parse(text = command), envir = .GlobalEnv))
     if (!class(result)[1] == "try-error")
         Rcmdr:::checkWarnings(readLines(messages.connection))
     result
}
<environment: namespace:RcmdrPlugin.DoE>

Subsequently, I am using the Rcmdr function errorCondition:
errorCondition <- function (window = top, recall = NULL, message = 
stop("message not supplied"),
     model = FALSE)
{
     tmp <- substitute({
         on.exit(remove(list = objects(pattern = "^\\.\\.", all.names = 
TRUE)))
         if (model) putRcmdr("modelNumber", getRcmdr("modelNumber") -
             1)
         if (!is.null(window)) {
             if (GrabFocus()) tkgrab.release(window)
             tkdestroy(window)
         }
         Message(message = message, type = "error")
         if (!is.null(recall)) recall() else tkfocus(CommanderWindow())
     })
     eval(tmp, parent.frame())
}

Function errorCondition has to find the dialog topdes2, and I have to be 
inside function Menu.pb2level again:
             hilf <- justDoItDoE(command)
             if (class(hilf)[1] == "try-error") {
                 errorCondition(window = topdes2, recall = Menu.pb2level,
                   message = gettextRcmdr(hilf))
                 return()
             }

This code does not work with topdes2 not in the search path, and when I 
tried before, it did also not work with getRcmdr("topdes2") instead of 
topdes2 - but maybe, I just was not following this approach through 
thoroughly enough.

Any thoughts whether the storage of widgets in an environment off the 
search path might work (when properly followed through, which will be a 
lot of work)? Or any suggestion how else I can achieve what I try to do?

Best, Ulrike

Am 13.02.2013 10:12, schrieb 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
>>