InputBox$ and the cancel button

[Kurt Kuzba]

I need some help to create a dialog like window so I can add 2 textboxes
to find a file name and then search within that file
I would like to have a second dialog popup called from the first dialog or inputbox$
i could not find a place to start a new topic
thanks
James Morgan

New topic HERE

https://forum.powerbasic.com/forum/user-to-user-discussions/programming/788054-custom-popup-input-box#post788054

[Jim Fritts]

Egbert's updated link to Safe wrapper for INPUTBOX$ in Source Code.

[Dale Yarker]

Each section has a "+ New Topic" button.

In the Samples\DDT\FileFind directory where PB is installed is code to search for a file. That can be modified for the second dialog.

(copy the files before changing, the samples will stay original)

Cheers,

[James C Morgan]

I need some help to create a dialog like window so I can add 2 textboxes
to find a file name and then search within that file
I would like to have a second dialog popup called from the first dialog or inputbox$
i could not find a place to start a new topic
thanks
James Morgan

[Michael Mattias]

I think it's equal.

VERIFY giveth position of offending character and does not require explicit MID$/ASC code; VERIFY taketh away what seems more natural to me:

  IF ISTRUE VERIFY (myString, "0123456789") THEN 
      MSGBOX "All characters of mystring are numeric digits"
  .....

Semantic, I know, but it is what "feels" correct to me.

MCM

[Egbert Zijlema]

>validates a "numbers only" setting
(...)
The PB VERIFY function is kind of funky... it returns FALSE (zero) on a "good" verification. Probably why it's often overlooked for this kind of editing.
(...)
The "plus offset" is, you get the position of the first offending character.
(...)

Well, PB's VERIFY function is not the only one. Quite a lot of Windows API functions return %ERROR_SUCCESS (= 0) if ending successful. What you call the "plus offset" is completely irrelevant in this routine. When one of the characters is invalid (don't mind which one), my routine simply re-runs to give the user a new chance.

So, I do not exactly understand your message. Did you just want to point me to an equal-worthy alternative or to a "far better solution"?

[Michael Mattias]

>validates a "numbers only" setting

  IF ISTRUE(iNumerals) THEN                           ' flag "digits only" is set
    FOR iPos = 1 TO LEN(sResult)
      SELECT CASE AS LONG ASC(sResult, iPos)
        CASE < 48, > 57
...

===>

IF Istrue (iNumerals) THEN
    IF ISTRUE VERIFY(sResult, "0123456789") THEN 
...

The PB VERIFY function is kind of funky... it returns FALSE (zero) on a "good" verification. Probably why it's often overlooked for this kind of editing.

The "plus offset" is, you get the position of the first offending character.

Or, in COBOL....

  IF sResult IS NOT NUMERIC THEN 
 ...

[Egbert Zijlema]

Safe wrapper in SC forum now

Given some incertainties throughout this thread, especially in respect with the cancel button, I've tried to create a "safe" wrapper for Power Basic's INPUTBOX$ function. Although it is a string function, my wrapper function also validates a "numbers only" setting.

You'll find it here: http://www.powerbasic.com/support/pb...221#post306221

[Dave Biggs]

LATER: Sorry, didn't read the help file very well. It is documented. See: ASC in Keyword Reference.

The apology should be made by me - I didn't make it clear I was quoting the help file - nor which part.

[Egbert Zijlema]

"If the string passed is null (zero-length) or the position is zero or greater than the length of the string, the value -1 is returned".

Position? Position of what?

Apart from that, a zero-length string obviously returns ascii -1. That's exactly what I said in my previous message. What I want to know is whether it's a documented feature or not.

LATER: Sorry, didn't read the help file very well. It is documented. See: ASC in Keyword Reference.

[Dave Biggs]

  sResult = ""
  MsgBox "Ascii code: " & FORMAT$(ASC(sResult)), 64, "Test Ascii code"

"If the string passed is null (zero-length) or the position is zero or greater than the length of the string, the value -1 is returned".

[Egbert Zijlema]

Empty string with ascii code -1?

It seems the InputBox$ function returns an empty string
when the Cancel button is clicked, even if a default string
is in the entry field. (...)

That's what I've always thought. But... if you query for the string's ascii code, -1 is returned. Can somebody explain this? I like to know if this is a safe method to verify if the user pressed the cancel button.

'  run this code and press the Cancel button to see that an empty string
'  returns an ascii value of minus one

#COMPILE EXE
#DIM ALL

FUNCTION PBMAIN () AS LONG
  LOCAL sResult AS STRING

  sResult = INPUTBOX$("First Name", "Test Inputbox$", "Egbert")
  MSGBOX "String content: " & sResult & $CRLF & _
         "String length: " & FORMAT$(LEN(sResult)) & $CRLF & _
         "Ascii code: " & FORMAT$(ASC(sResult)), 64, "Test Inputbox$"
END FUNCTION

[Michael Mattias]

if cancel or the x to close, causes the returned string to be nothing.

That sure doesn't sound like the 'correct' behavior if one supplies a 'default' value.

Maybe that should be called an "initial" value instead of a "default" value.

Regardless, this behavior should documented.

[Cliff Nichols]

You are right. Dummy me staring at the same block of code so long that until
I came home and took a break, it was then obvious that if cancel or
the x to close, causes the returned string to be nothing.

My other problem was a check to verify that the value of the string would not be
zero (and obviously the value of nothing is zero)

Thanks to all

------------------

[Fred Harris]

It seems the InputBox$ function returns an empty string
when the Cancel button is clicked, even if a default string
is in the entry field. That makes sense kind of. Just tried
it with my code above.

------------------
Fred
"fharris"+Chr$(64)+"evenlink"+Chr$(46)+"com"

[Michael Mattias]

If you need to know if he canceled rather than simply 'did not changed the default,' perhaps INPUTBOX$ is not the optimal choice of functions here.

      Prompt  [editable default]
    
          <OK>   <Cancel>

I think that's about a ten-minute DDT dialog job....

[Fred Harris]

Just tried this and it seems to work

#Compile Exe
#Dim All

Function PBMain() As Long
  Local strText As String, strResult As String
  
  strText="December"
  strResult=InputBox$("Enter A Month",,strText)
  If Len(strResult) Then
     MsgBox("User Entered " & strResult)
  Else
     MsgBox("User Cancelled!")
  End If
  
  PBMain=0
End Function

------------------
Fred
"fharris"+Chr$(64)+"evenlink"+Chr$(46)+"com"

[Fred Harris]

Cliff,

Couldn't you just compare the default string before and
after? If it isn't the same, then the user changed something.
If it is the same, perhaps he hit cancel. Havn't tried it,
that's just my guess.

------------------
Fred
"fharris"+Chr$(64)+"evenlink"+Chr$(46)+"com"

[Cliff Nichols]

This should be simple but I can find no information via search or in POFFS

If I use an inputbox$, how do I know if the user pressed the cancel button?
(Checking the length of the string is no good because I set a default value)

Do I have to make my own custom input dialog so that I can check which button was pressed?

should be a simple answer, but I am guessing I will have to go custom?

------------------