[Rd] Private environments and/or assignInMyNamespace

[Ulrike Grömping]

Dear John and Milan,

thanks a lot for your input. Unfortunately, this is by far not the only 
think preventing my dialog from working, I am afraid. This was the start 
of the matter, as far as I remember, but I think that buttons like my 
refresh button etc. will also need special attention - as my plugin was 
written, before Rcmdr knew how to make dialogs remember their settings, 
I created constructions for that as well. I suppose that I have to bite 
the bullet at some point and try for one of the dialogs whether I can 
make it work by thoroughly applying putDoE and getDoE (i.e. assigning to 
and retrieving from my own private environment) to all affected widgets.

Best, Ulrike

Am 13.02.2013 15:35, schrieb John Fox:
> Dear Milan and Ulrike,
>
> The purpose of errorCondition() is to put a dialog in the state it was in prior to the erroneous input, reflecting, e.g., prior selections. Like all Rcmdr utility functions, its use isn't mandatory -- it's simply meant to be convenient and to encourage some consistency in behaviour in the Rcmdr and plug-ins.
>
> If you prefer to have a dialog remain in its erroneous state after an error -- and I can see an argument for that -- then you needn't use errorCondition().
>
> Finally, if this is the only thing preventing Ulrike's dialogs from working, then avoiding errorCondition() an attractive solution.
>
> Best,
>   John
>
> On Wed, 13 Feb 2013 14:24:01 +0100
>   Milan Bouchet-Valat <nalimilan at club.fr> wrote:
>> Le mercredi 13 février 2013 à 13:16 +0100, Ulrike Grömping a écrit :
>>> 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?
>> OK, this is what I suspected. John should probably comment this
>> statement, but I do not really understand the purpose of the
>> errorCondition() function. I've stopped using it in my own RCommander
>> plug-in.
>>
>> What I would do if I had to solve your problem is to call return()
>> instead of errorCondition(), so that the dialog is left as-is. To tell
>> the user that something is wrong, you can use Message(), or show an
>> error dialog or a label in the original dialog right before calling
>> return(). This is the simplest solution and it does not require any
>> programming trick. But maybe I'm missing something. ;-)
>>
>>
>> My two cents
>>
>>> 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
>>>>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel