Garrett,
Ah, now I think I see what you meant.
Let me preface by saying that what you're trying to do probably should be possible. You should be able to read from the stdin stream without locking up mged. That is probably a bug in the command intepreter that mged coordinates with Tcl. I've added it to our bugs list so someone can hopefully look into the problem and work on a fix.
In the meantime, to prompt for user input, there is a work-around hack that you can use that avoids the stdin channel. If you truely want to *interactively* prompt the user for input in ask-a-question-then-get-an-answer fashion, you can rather readily do this regardless of mged's closure of "stdin" by opening a readable pipe as shown in the proc below: (assumes glob_compat_mode is 0)
proc mygets { } {
set pipe [open "| cat" r]
fconfigure $pipe -buffering line
catch {set data [gets $pipe]}
catch {close $pipe}
set data
}
Then to use the new command, I can query for input as needed:
mged> mygets myvar
This is a test
mged> puts $myvar
This is a test
mged>
The big deficiency with this hack is that you have to hit return twice to terminate the mygets input. If you're prompting interactively, you could certainly include that detail along with the prompt to the user and it's of course fugly, but it does work.
That said.. tricking the "error" command to serve as an input prompt is quite interesting! Heh, I don't think I even realized what it was doing until I read the script and your e-mail again and then had to try it out... That is undoubtedly even a better approach than the mygets hack above.
Cheers!
Sean
On Tuesday, February 27, 2007, at 08:48PM, "ghollandsr" <ghollandsr@...> wrote:
>Sean,
>
>No worries about getting back to me in a hurry, I'm having to play with this
>in my spare time.
>
>What I was trying to do was actually prompt the user for input while in GUI
>mode. I looked at a lot of the Tcl scripts to see how some of those managed
>it. The one I found, was the prj_add.tcl script. There is a switch statement
>in there that basically prompts the user for input when it was lacking in the
>command call and adds that to the args. (It sure took me a looong time to
>figure out that 'args' was a keyword and not just any old variable name.)
>Doing that looks like it would be a way to mimic what I would expect from
>gets, when mged is in GUI mode. I just figured there had to be a better or
>easier way to do this.
>
>The line that adds to the $args variable is something like:
>
>error "more arguments needed::[lindex $prompts $i]"
>
>This strange looking construct prints a prompt from an array of prompts and
>waits for the user to type an argument. That argument gets added to $args as
>if it had been entered on the command line. I figured that I can use that to
>prompt the user for input. But, at least to me, this is like voodoo, I'm not
>even sure why it works. Of course, I'm a noob, note that it didn't occur to
>me to use eval to flatten a list.
>
>Thanks for the help,
>Garrett Holland
>
>I'm convinced that we can travel faster than light one day, cause if I have
>spare time, then the concept of imaginary time can't be too far fetched.
>

An excellent question came up recently as to how one can change the
default directory that MGED uses when using the File->Open and File->New
dialogs, among others. This is a particularly annoying problem on Windows
where it currently starts you off where the MGED application was
installed, which is probably not where your files are located. To change
this behavior to something different, here are some example settings:
# example path on Windows
set mged_gui(databaseDir) {C:\Windows\Desktop}
# another example path for Windows
set mged_gui(databaseDir} {C:\Documents and Settings\username}
# example path on other systems
set mged_gui(databaseDir) {/usr/tmp}
# another example path that uses Unix HOME variable
set mged_gui(databaseDir) "$env(HOME)/geometry/stuff"
Add one of those to you .mgedrc configuration file above the MGEDRC_HEADER
line and you should be good to go after restarting MGED.
Cheers!
Sean