Jump to content
Sign in to follow this  
TFM

Custom Dialog Script Step... Is it buggy?

Recommended Posts

I have a custom solution that heavily uses the Custom Dialog script step.

This is something that should have been in version 1, but anyway...

So it works great. You can have up to three fields. It works directly in find mode or for entering in text and passwords... BUT...

Here's my issue. If you click ANY button other then the default far right one, it doesn't actually use the text you put in the text box(s)!

So I can't use something that says something like this...

Enter User Name: <Field>

[Cancel] [No More] [More]

Any button other then [More] results in the text NOT getting recorded!

Any help would be useful as I bought V6 Dev just for this feature.

TFM

Share this post


Link to post
Share on other sites

Hi TFM,

Just checked, and you are totally right.

I could see the logic of a 'Cancel' button always behaving like this, but the way it is now is indeed not logical or plainly a bug.

What platform are you using? I'm on a Mac.

Regards,

Ernst

Share this post


Link to post
Share on other sites

I'm on a PC.

I'm glad I'm not the only one. I can't beleive this wasn't spotted right away. Does Filemaker have any way of reporting bugs without having to hand over your Visa?

Thanks

TFM

Share this post


Link to post
Share on other sites

Save yourself a lot of hassles and buy the Troi Dialog Plugin or similar. You get more features. www.troi.com

Then you have to buy it, it has a pop up when it loads and it makes distribution of your solution with hassle...

Share this post


Link to post
Share on other sites

I'm not sure it can be considered a bug ... Given that one button "accepts" the data and one "refuses" them the third button could have been given either function, and IMO setting it to refuse data was a conservative choice (IOW accept data only when the user explicitly says so) that I agree with.

BTW I've almost never used it since I usually use a Dialog.fp5 file to do this kind of operations, a much more powerful and flexible option

Share this post


Link to post
Share on other sites

I'm not sure it can be considered a bug ... Given that one button "accepts" the data and one "refuses" them the third button could have been given either function, and IMO setting it to refuse data was a conservative choice (IOW accept data only when the user explicitly says so) that I agree with.

You've got a point there, though I really think Filemaker should have made the function (accept data or not accept data) selectable for the programmer.

But Filemaker has got a lot of these 'easy to implement but yet missing' features, that they are probably saving up for future updates, when they run out of money... grin.gif

Best regards,

Ernst

Share this post


Link to post
Share on other sites

If you buy the developer's license, Troi's nag screen won't ever appear, and you can distribute as many copies as you wish.

Look, Filemaker is a collection of clowns...don't hold you breath waiting for them to fix anything. My guess is that we'll get a flock of buggy, poorly implemented 'improvements' that we could live without. There are bugs in the software for years that they haven't found the need to fix.

Steve

Share this post


Link to post
Share on other sites

If you buy the developer's license, Troi's nag screen won't ever appear, and you can distribute as many copies as you wish.

Really? Well, I'm glad that someone listened, years ago we tried to release a solution with a plug-in and it no end of horror.

Look, Filemaker is a collection of clowns...don't hold you breath waiting for them to fix anything. My guess is that we'll get a flock of buggy, poorly implemented 'improvements' that we could live without. There are bugs in the software for years that they haven't found the need to fix.

You do have a very valid point there. I used to be an FMP developer in V3/4 days. I come back 3! VERSIONS later and most of the same ******* bugs and annoyances are still there! Thankfully I've managed to make a work around for this dialog hassle. But I'll check out that plug-in again.

Share this post


Link to post
Share on other sites

Don't forget also the 24u plugins -- www.24u.cz.

Simple dialog is very powerful and cheap, and it is fat-fat-fat plugin. Single compilation is working on any platform.

Share this post


Link to post
Share on other sites

Anatoli said:

Don't forget also the 24u plugins -- www.24u.cz.

Simple dialog is very powerful and cheap, and it is fat-fat-fat plugin. Single compilation is working on any platform.

I was just tripped up by this today and wanted to note that this URL is dead.

Share this post


Link to post
Share on other sites

I got a reaction from Filemaker! But don't hold your breath...

I reported that the custom dialog only 'saves' the data entered when your press the default button. Got this reaction:

Dear sir,

What exactly do you mean by 'saves' ?

When using a script you need to use the status function "Status

(CurrentMessageChoice)" in order to catch the button selected by the user.

You can use this function in a 'if' statement in order to act accordingly.

Share this post


Link to post
Share on other sites

I was just troubleshooting the same issue (Show Custom Dialog) and have verified your results.

FileMaker Pro 6 will only store Custom Dialog "Input Field" data entries when the rightmost default button is clicked. This does seem like a bug and not a feature.

Please share any other information you find regarding this issue. Thanks.

Share this post


Link to post
Share on other sites

After submitting about 100 bug reports on this to FileMaker, they finally responded and said this is expected behavior, it is not considered a bug, and it will not be changed.

Blasphemy, I say. Blasphemy.

Seriously though, this irks me something awful. I don't understand how this could be considered acceptable. The button a user clicks should have no bearing on the data that user enters - the two should be completely seperate. The business logic triggered by any button should be left untouched for the developer to implement.

But, *it gets worse*! Think about this for a second: As a user, you see an input dialog. You enter data. Then you think, wait no, this isn't what I want to do. What does your instinct tell you to do next? For many people, their instinct is to hit the "esc" key and cancel the dialog.

OK, now think about this: To retain user input, the user must click button #1. However, button #1 is also the default button. AND DIG THIS: The "esc" key triggers the default button! So the "esc" key also acts as the SUBMIT key for dialogs, and you have no control over this. WOW!

Now, having reviewed that, please, somebody, explain to me how this is not considered a bug.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.