1. enhancing prompt() functions

I would like to enhance the prompt_string() function to allow the user to supply a default or initial string to be used.

For example:

 
   uname = "Steve Jones" -- could be retrieved from a database, prefs file, or whatever 
   uname = prompt_string( "Enter username: ", uname ) 

Or is there another/a better way to go about this?

new topic     » topic index » view message » categorize

2. Re: enhancing prompt() functions

euphoric said...

I would like to enhance the prompt_string() function to allow the user to supply a default or initial string to be used.

For example:

 
   uname = "Steve Jones" -- could be retrieved from a database, prefs file, or whatever 
   uname = prompt_string( "Enter username: ", uname ) 

Or is there another/a better way to go about this?

This approach is quite difficult, because we just use gets(0). Even if we fall back to C code, to handle fgets() we'd have to use ungetc() to push back the characters in the initial string - and ungetc() only guarantees one push back (thus one character).

So, we have to drop gets() and use wait_key() and puts() and handle the edit processing ourselves. This is a lot more complicated than the existing prompt_string() function. OTOH, ed.ex already does this.

new topic     » goto parent     » topic index » view message » categorize

3. Re: enhancing prompt() functions

jimcbrown said...
euphoric said...

I would like to enhance the prompt_string() function to allow the user to supply a default or initial string to be used.

For example:

 
   uname = "Steve Jones" -- could be retrieved from a database, prefs file, or whatever 
   uname = prompt_string( "Enter username: ", uname ) 

Or is there another/a better way to go about this?

This approach is quite difficult, because we just use gets(0). Even if we fall back to C code, to handle fgets() we'd have to use ungetc() to push back the characters in the initial string - and ungetc() only guarantees one push back (thus one character).

So, we have to drop gets() and use wait_key() and puts() and handle the edit processing ourselves. This is a lot more complicated than the existing prompt_string() function. OTOH, ed.ex already does this.

I'm not sure why we'd need to do all of that. Using the example above, it might look like:

Enter username: [Steve Jones]  
Then, if you simply press enter, it's as though you entered Steve Jones. Otherwise, whatever the user enters is returned.

Matt

new topic     » goto parent     » topic index » view message » categorize

4. Re: enhancing prompt() functions

jimcbrown said...
euphoric said...

I would like to enhance the prompt_string() function to allow the user to supply a default or initial string to be used.

This approach is quite difficult, because we just use gets(0).

Yes, I discovered that after looking at the function. I'm guessing a roll-your-own solution will have to do for now.

Thank you! :)

new topic     » goto parent     » topic index » view message » categorize

5. Re: enhancing prompt() functions

mattlewis said...
jimcbrown said...
euphoric said...

I would like to enhance the prompt_string() function to allow the user to supply a default or initial string to be used.

For example:

 
   uname = "Steve Jones" -- could be retrieved from a database, prefs file, or whatever 
   uname = prompt_string( "Enter username: ", uname ) 

Or is there another/a better way to go about this?

This approach is quite difficult, because we just use gets(0). Even if we fall back to C code, to handle fgets() we'd have to use ungetc() to push back the characters in the initial string - and ungetc() only guarantees one push back (thus one character).

So, we have to drop gets() and use wait_key() and puts() and handle the edit processing ourselves. This is a lot more complicated than the existing prompt_string() function. OTOH, ed.ex already does this.

I'm not sure why we'd need to do all of that. Using the example above, it might look like:

Enter username: [Steve Jones]  
Then, if you simply press enter, it's as though you entered Steve Jones. Otherwise, whatever the user enters is returned.

I don't see an easy way to get "Steve Jones" into the buffer, which I think is what would have to happen.

I'm going to try a puts(0,default) and see if that works. :)

Edit: It doesn't work. :/

new topic     » goto parent     » topic index » view message » categorize

6. Re: enhancing prompt() functions

mattlewis said...

I'm not sure why we'd need to do all of that. Using the example above, it might look like:

Enter username: [Steve Jones]  
Then, if you simply press enter, it's as though you entered Steve Jones. Otherwise, whatever the user enters is returned.

Matt

Hmm. I guess that's fine.

The user couldn't edit the default string (e.g. change it from "Steve Jones" to "Steve Jone") but would either have to use it as-is or type in the whole thing from scratch, but that might not be a problem.

new topic     » goto parent     » topic index » view message » categorize

7. Re: enhancing prompt() functions

jimcbrown said...
mattlewis said...

I'm not sure why we'd need to do all of that. Using the example above, it might look like:

Enter username: [Steve Jones]  
Then, if you simply press enter, it's as though you entered Steve Jones. Otherwise, whatever the user enters is returned.

The user couldn't edit the default string (e.g. change it from "Steve Jones" to "Steve Jone") but would either have to use it as-is or type in the whole thing from scratch, but that might not be a problem.

Oh, I see what you're saying. heh.

new topic     » goto parent     » topic index » view message » categorize

8. Re: enhancing prompt() functions

euphoric said...

I'm going to try a puts(0,default) and see if that works. :)

That's hard to do (even in C) for reasons I previously stated.

On the Windows (non-MinGW) side, we can add support in be_runtime.c's key_gets() function. We already appear to be handling editing in there, so we'd just need to add a pushback buffer.

We don't use key_gets() on MinGW or POSIX, however. On MinGW we use the W32API console api, so it might be possible to push back characters that way.

new topic     » goto parent     » topic index » view message » categorize

9. Re: enhancing prompt() functions

This seems to work OK:

 
public function prompt_string(sequence prompt, sequence default = "") 
	object answer 
 
	puts(1, prompt) 
	if length(default) > 0 then 
		puts(1," [" & default & "] ") 
	end if 
	answer = gets(0) 
	puts(1, '\n') 
	if sequence(answer) and length(answer) > 0 then 
		answer = answer[1..$-1] -- trim the \n 
	end if 
	if length(answer) > 0 then 
		return answer 
	else 
		return default 
	end if 
end function 

To test:

sequence s = prompt_string( "Enter username:", "Billy Ray Jones") 
puts(1,"\n'" & s & "'\n\n") 
new topic     » goto parent     » topic index » view message » categorize

10. Re: enhancing prompt() functions

euphoric said...
mattlewis said...

I'm not sure why we'd need to do all of that. Using the example above, it might look like:

Enter username: [Steve Jones]  
Then, if you simply press enter, it's as though you entered Steve Jones. Otherwise, whatever the user enters is returned.

I don't see an easy way to get "Steve Jones" into the buffer, which I think is what would have to happen.

I'm going to try a puts(0,default) and see if that works. :)

Edit: It doesn't work. :/

Well, in my console (konsole), I can copy and paste, and edit whatever's there. And then I get the end result:

include std/console.e 
printf(1, "you entered: [%s]\n", { prompt_string("enter something:") }) 

Matt

new topic     » goto parent     » topic index » view message » categorize

11. Re: enhancing prompt() functions

I guess I could brush off my Textmode Dialogs lib. I think it has all sorts of functionality in there, even text prompts with default values... IIRC. :D

new topic     » goto parent     » topic index » view message » categorize

12. Re: enhancing prompt() functions

euphoric said...

I guess I could brush off my Textmode Dialogs lib. I think it has all sorts of functionality in there, even text prompts with default values... IIRC. :D

If it works across platforms, it would be a nice addition to the std lib.

Jeremy

new topic     » goto parent     » topic index » view message » categorize

13. Re: enhancing prompt() functions

jeremy said...
euphoric said...

I guess I could brush off my Textmode Dialogs lib. I think it has all sorts of functionality in there, even text prompts with default values... IIRC. :D

If it works across platforms, it would be a nice addition to the std lib.

Jeremy

I have an updated version on my PC. I've squashed some bugs and will make it available to others for testing.

It's based on Irv Mullins' original text-mode dialogs library, just with some added usability enhancements.

new topic     » goto parent     » topic index » view message » categorize

14. Re: enhancing prompt() functions

jimcbrown said...
euphoric said...

I'm going to try a puts(0,default) and see if that works. :)

That's hard to do (even in C) for reasons I previously stated.

On the Windows (non-MinGW) side, we can add support in be_runtime.c's key_gets() function. We already appear to be handling editing in there, so we'd just need to add a pushback buffer.

We don't use key_gets() on MinGW or POSIX, however. On MinGW we use the W32API console api, so it might be possible to push back characters that way.

I'm currently rewritting the console input functionality so that in Windows (regardless of compiler) it just uses the Windows API and thus putting characters into the console buffer is quite easy to do.

new topic     » goto parent     » topic index » view message » categorize

15. Re: enhancing prompt() functions

DerekParnell said...
jimcbrown said...
euphoric said...

I'm going to try a puts(0,default) and see if that works. :)

That's hard to do (even in C) for reasons I previously stated.

On the Windows (non-MinGW) side, we can add support in be_runtime.c's key_gets() function. We already appear to be handling editing in there, so we'd just need to add a pushback buffer.

We don't use key_gets() on MinGW or POSIX, however. On MinGW we use the W32API console api, so it might be possible to push back characters that way.

I'm currently rewritting the console input functionality so that in Windows (regardless of compiler) it just uses the Windows API and thus putting characters into the console buffer is quite easy to do.

Right now it's in three places. That welcome rewrite would bring it down to two.

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu