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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
