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