[Rd] Private environments and/or assignInMyNamespace

[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