From nalimilan at club.fr  Wed Feb 13 14:24:01 2013
From: nalimilan at club.fr (Milan Bouchet-Valat)
Date: Wed, 13 Feb 2013 14:24:01 +0100
Subject: [Rd] Private environments and/or assignInMyNamespace
In-Reply-To: <511B842E.6030408@bht-berlin.de>
References: <511A4785.5070504@bht-berlin.de>
	<1360746723.28045.23.camel@milan> <511B842E.6030408@bht-berlin.de>
Message-ID: <1360761841.28045.45.camel@milan>

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
> >>



[Rd] Private environments and/or assignInMyNamespace
Milan Bouchet-Valat