Custom Dialog Input Fields

[Racer Bob]

Can't find anything on this in the forum but I can't get the input field function of the Show Dialog step to pass the value to the record. I have a record in a portal and wish to change one date field which then is followed in the script by recalculating another field in the record. All goes well until I authorize the acceptance of the new value in the dialog box, the returned value of 1 (right button).

This is supposed to allow the input value to replace the original in the field. The existing field value is shown in the input value box so it must be looking at the corrct record and field.

But when the script step is completed the new field value is a ? and the following recaluation step doesn't seem to have been executed. There are no limitations on changing the field value in the browse mode, only the find mode. Any one have an idea, the included help info is a little too much jargon and not enough detail on the nuts and bolts of how things work.

[Inky Phil]

Hi Bob and welcome to the forums.

Here are my thoughts as raised by reading your post.

How are you resetting the value in the record. Are you using a script? If so can you post the sample script.

If there is only 1 record in the portal/relationahip why not just put the field from the related record field directly into the dialogue box thereby negating the need to set the field at all.

Whenever I see a '?' in a field I first look to see if the field is big enough to display the data and then I also check that I haven't replaced the data in that field with data of the wrong type ( ie placing text into a date field)

HTH

Phil

[Racer Bob]

Thanks for responding Phil

I have yet to find a way to copy or print a script out of the program despite what the instructions say, copy option doesn't appear anywhere. As for your questions

1. The whole process is in a script since Custom Dialog is a script step.

2. There are numerous records in the table displayed in the Portal

3. As per the instructions, the input field option of the Custom Dialog is set to the actual table field for the selected record. This seems to match as the existing value of the field appears in the input box of the Custom Dialog.

I included the Go To field step as I found that if I did not move the cursor to the desired field before executing the Dialog step, the new data, or in this case the ?, was placed in what ever field was selected when the Dialog box step was started. Seems to be independent of what field is specified for the input.

4. The value should be changed to the new input upon completion of the Dialog box function, as per the instructions by using the OK button which returns a value of 1.

5. The new entry into the field is the same type (Date) as the existing value so there should not be a problem displaying the changed value.

Hand entered copy of script

Allow User Abort (on)

If [Get(PortalRowNumber)=0]

Beep

Show Custom Dialog["Parts Replacement": "Must first select Row of part to replace"]

Exit Script []

EndIf

Go To Field [Parts::Date Installed]

Show Custom Dialog [" Replace"; Enter Replacement Date, Hours will be updated";Parts::Date Installed]

If[Get(LastMessageChoice) {NOT EQUAL;see note below}1]

Exit Script[]

EndIF

SetField[Parts::Hours at Install=Vehicles::Total Hours Run]

Commit Records/Requests[]

Note required symbols won't show in this text entry format nor is indenting of nested If steps

<>

[comment]

Can you explain what your script does (or is supposed to do), that the attached file does not?

CustomDialog.fp7.zip

[Raybaudi]

Hi

try these two steps only:

Show Custom Dialog [" Replace"; Enter Replacement Date, Hours will be updated";Parts::Date Installed]

Commit Records/Requests[]

... but the button that fires the script must be inside the portal row.

Edit: comment, I haven't see your post B)

[Racer Bob]

To all who responded, Thanks. Looking at some of the responese prompted me to go through the process of eliminating selected steps to see what worked and what didn't.

The answer lies in the improper entry of the SetField step. It read

Set Field[Parts::Hours at Install =Vehicles::Total Hours Run]

The correct form is

Set Field[Parts::Hours at Install;Vehicles::Total Hours Run]

The incorrect form confused the program as to what field was being set since it only had the calculation. The ? denoted that the number was being placed in the last selected field which is a Date type field. Additionally, it returned a Boolean result for the Parts::Hours At Install = Vehicles::Total Hours Run entry in the calculation part.

This means that if the correct field is selected for the cursor position or active field, that just putting a calculation in the brackets worked, the field specifier is an option. It would have worked fine if I had included another Go To Field [Parts::Hours at Install]. This would have then placed the calculation in the correct field. Either method works, the difference is one scrip step verses two script steps.

All the other steps work fine. The button is in the header and works fine. The layout is set to the Vehicles table and the Portal is set to the Parts table. This allows scrolling through the vehicles and the related parts in the portal automatically change to match. The purpose of the file is to keep track of the hourly usage of parts on race cars, which are serviced and changed out at pre set hourly figures.

As to the example file from Comments, unfortunately the file when unzipped would not load being declared damaged, corrupted or not a FileMaker file. So I didn't get a chance to see what it did.

Edited January 30, 2007 by Guest

[mr_vodka]

As to the example file from Comments, unfortunately the file when unzipped would not load being declared damaged, corrupted or not a FileMaker file. So I didn't get a chance to see what it did.

Downloads, unzips, and opens fine for me. Maybe you should update your zip application or get a new one.

[Racer Bob]

Well now this gets interesting. I do in deed have the latest update to my WinZip. Upon unzipping the file, two copies are created, one in the folder I have specified and another in a sub folder labled "_MACOSX". I don't really know why, I didn't specify any such thing. The subfolder version will not run but the one in the folder I specified will. Another Windows based program thing ?

As to the example, it does work but has two draw backs for me.

1. It requires using screen space in each row of the portal, which in my case is at a premium. It also repeats the button which seems unnecessary.

2. It has no provision for altering the associated hours field for the record. In the end a more detailed script is required.

What it does do is make sure that the correct record is always selected, which my script handled with a test of position. Just proving there are more ways to accomplish objectives.

Thanks again folks.

[mr_vodka]

Upon unzipping the file, two copies are created, one in the folder I have specified and another in a sub folder labled "_MACOSX". I don't really know why, I didn't specify any such thing. The subfolder version will not run but the one in the folder I specified will. Another Windows based program thing ?

This folder is created when Mac users zip up files. Since Comment used a mac, thus the subfolder.

1. It requires using screen space in each row of the portal, which in my case is at a premium. It also repeats the button which seems unnecessary.

Wrong. This step was necessary. The button is on the portal so that it could reference the specific related record.

As Daniele pointed out to you in an earlier post...

Hi

... but the button that fires the script must be inside the portal row.

2. It has no provision for altering the associated hours field for the record. In the end a more detailed script is required.

This is an interface design issue more than a problem with the field returning a result of "?"

[comment]

This is a demo, so the button is clearly marked as such. In your implementation, you can turn any object in the portal into a button - or place an invisible rectangular button behind the objects in portals, thus saving space.

The only purpose of the demo was to show how many unnecessary steps your script had. If you need additional functionality, you will need to add more steps. A Commit Records/Requests[] at the end of the script, as Daniele suggested, would be very appropriate.

[Racer Bob]

The thing about the apple zipped file is interesting. Another not mentioned up front feature in the WinZip program. Could not the program detect the system it is running on and make the adjustment. Not much point creating a folder and file that isn't readable along with the necessary file. Now I just have an unwanted folder and file. Humm

As to the comments, all very good points however consider the following.

First the script makes sure the user has in fact selected a row in the portal. Why, to make sure a row is actually selected so one of several options can be perfomred on that record

From just the one portal on one layout displaying the records I have the ability to:

1- Add new records

2- Edit existing records

3- Record a part replacement date and adjust hours in service for each part

4- Record a service date and adjust hours since serviced for each part.

To do all these requires a different script for each option. If I set a field on the portal to act as a button then I am limited to just that scripted action for that field.

As an example, for a new record the portal is moved to the bottom of the records and creates an empty row. In turn this includes functions that associate the newly added part with the internal vehicle ID and sets the correct beginning hours for the new part. These actions are not the same as the replace part option.

If I set a button for the replace part script behind the Put in service/Replacement date field then that will be activated when attempting to enter the new part date. This in turn would effect the hours field and has potential to confuse the user as well as the program. I feel good programming should never assume the user fully understands how the program works behind the scene.

For editing I can limit changes to only selected fields to avoid the user confusing the records.

For a part replacement I only want to change the put in service / replacement date and have the hours in use automatically adjusted without user action.

For a Service I only want the service date changed and again the hours at service are automatically adjusted without user action.

Additionally, there has to be some way to let the user know how to select the various actions, such as clicking on the replacement date field verses the service date field. I never assume the user knows that to perform a certain option they must take a specific, unlisted on the screen, action. Cluttering the screen with lots instructions is not acceptable to me so some sort of pop up instructions have to be available which means more buttons and dialog scripts.

One alternative is to open a dialog box each time the field is selected and ask the user if they do indeed want to perform the associated action. Then a choice has to be made based on the users answer which takes more scripting. This means a user, when at the date field while adding a new part, is confronted with a dialog asking if they are indeed replacing the part. This could be confusing to the user and should never happen.

The only other option is to figure out a way to prevent the running of the scripts associated with the portal fields when another option is being performed, such as not running the Replace Part script when adding a new part. Some how it has to be made know what the user is doing, adding, replacing or servicing. That means more buttons which is more complication in the scripts. I am sure there is a way to do all this but again, that is more complication. I prefer to keep it as simple as possible for the user, believing it is the programmer's job to do the hard part.

The way I have done it requires just one portal display in one layout with a row of tabs just above the portal to allow the user to select which of several options they wish to perform.

Others may prefer different apporaches but this has worked well for me on commerical software in the past, in the days when we actually used assembly language and didn't have huge amounts of memory to play with. When the users don't get confused, as happens all too often with today's programing, I consider the operation a success.

[LaRetta]

Not much point creating a folder and file that isn't readable along with the necessary file. Now I just have an unwanted folder and file. Humm

This is a WINDOWS thing alone. ALL zips do it because it is how Windows converts. Welcome to cross-platform work. It's annoying but simple to solve - delete them. Certainly not worth getting irritated about. We on Windows have plenty of OTHER things we can get irrated at. :wink2:

[comment]

I wasn't aware of the problem with Mac-zipped files. I'll try and look into it.

[comment]

I believe that actions affecting a selected portal row should be initiated from the portal row itself directly - without requiring the user to (a) select the portal row, and ( click outside the portal to select the action. Adding a new row is a different matter.

Of course, I haven't seen your solution, so I can only speak generally. If I had so many options to modify the related record, I think I would let the user select the record for detailed editing in a new window.

[LaRetta]

I doubt there is any way to stop it, Michael. I've never received an archived file from Mac that Windows didn't create the extra folder when converted. :wink2:

[Raybaudi]

Hi all

when I open a zipped file, I drag and drop the win file on the desktop, close the zip file and trash it.

[comment]

How's this one?

Untitled.fp7.zip

[LaRetta]

No darned Mac folder. Not what I expected but I should have known better. ;-)

Share please, I'll need it with my Mac when I send zips.

Edited January 31, 2007 by Guest

[Inky Phil]

Don't be fooled LaRetta, he might have done it on a pc

:Whistle:

[LaRetta]

:jester:

I recall asking the question about that Mac folder when I first started on Forums. I had spent an hour trying to figure out what to do with it and why it happened. I was just told 'it's life.' I'll bet Michael created it on a Mac and figured it out!

[mr_vodka]

Command line possibly? B)

[mr_vodka]

Hmm after some researh, I found this forum regarding the ResourceFork with Zip file issue

[comment]

I have used DropStuff to zip the file, rather than the standard OS X BOMArchiveHelper. I have set DropStuff's ZIP preferences to NOT preserve Macintosh content.

This is a rather tedious procedure for me, so I am afraid my future posts will revert back to annoy you Windows users. I wish BOMArchiveHelper had the same setting (or any settings at all, for that matter).

I THINK another way to achieve the same result would be to mail the file to yourself as a "Windows-friendly" attachment, then zip it. And of course, there are several file utilities that can remove the resource fork.

Why don't y'all switch to Mac - that would be much simpler...

[mr_vodka]

Why don't y'all switch to Mac - that would be much simpler...

Haha. A few years ago I would have said no way but after they went UNIX, I loved them. However, barring design/arts/media/etc. companies, most are predominately PC based.

B)

[Lee Smith]

When I down load a Mac Stuffed file .sit, it will give me a folder. The folder is named with the file, proceeded with the post number.

I have not had this happen with a zip that I download.

BTW LaRetta, once you start using the Mac, all of this stuff will become a distant memory.

Lee

[Lee Smith]

I have Virtual PC and Windows for all of the analytical programs that I need for my financial counseling business, and there isn't a problem with them running at all.

Lee