Custom Dialog Script Step... Is it buggy?

[TFM]

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

[ernst]

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

[TFM]

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

[ernst]

Yes they do.

http://www.filemaker.com/company/product_problems.html

I al ready submitted.

Let's hope that more readers of this thread do...

Regards,

Ernst.

[Ugo DI LUCA]

FileMaker released an update for 6 but apparently it doesn't mentionned this bug even if it seems ther was another one with the custom dialog...

FMI TechInfo

[SteveB]

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

Steve

[TFM]

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...

[Pupiweb]

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

[ernst]

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...

Best regards,

Ernst

[SteveB]

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

[TFM]

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.

[Anatoli]

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.

[lakeside]

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.

[Lee Smith]

This is the address for 24u software.

http://www.24uSoftware.com/

Lee

[ernst]

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.

[rreci]

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.

[Mariano Peterson]

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.