Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Editing/Adding records EASILY in portal: requires version 6? 2
- Thread starter Webnewbie
- Start date
-
1
- #2
I don't understand what adding records in portals has to do with scripting. What are you trying to do?
I moved from 5.0 to 6.0. The scripting is the same. Maybe a few more choices but I guess you could call it clunky. I find them predictible and easy to create. I ungraded to the developer version of 6.0. The scripting is much easier with that version because it allows you to step through your scripts one line at a time.
Marty
I moved from 5.0 to 6.0. The scripting is the same. Maybe a few more choices but I guess you could call it clunky. I find them predictible and easy to create. I ungraded to the developer version of 6.0. The scripting is much easier with that version because it allows you to step through your scripts one line at a time.
Marty
- Thread starter
- #3
Thanks for replying. I am pretty much new to portals. Let's say we have a portal screen with Author as the Main Screen and then a Portal (not repeating records). All the books by that one author are shown in the portal. I want to be able to type right in the portal. I want to be able to edit or create new records (new titles by that author) right in the portal.
This feature comes with 6.0 right out of the box. No scripting is necesary. But...my client may not go with 6.0 and they may stay with 5.5. They have very limited resources so even a couple hundred $ to upgrade to 6 might not be possible.
So...I want them to be able to type right in the portal. The reason is, is that when they have serveral files (databases) open at the same time like AUTHORS and TITLES, switching between the files is too clunky for them. It is just not going to work easily. They are doing that now and making too many mistakes. More training in FM Pro may not help much. SO...I hope to have them type new records in the portal. Please keep in mind that they are very busy answering phones, running their business, etc. As a developer I want to make things very simple for them. This is the only way things will work out well for them. The concept of switching between files may seem easy for you and I, but that is not going to work for them. Because that is confusing and difficult for them, they hired me. I want to take advantage of a "live" portal. Yes, it's available in Version 6. Is it POSSIBLE in version 5.5 in an EASY way? I've seen scripting for this for 5.5, but you have to click a button, choose the field to change for EVERY field. This will not be smooth enough for a client needs a VERY simple process.
This feature comes with 6.0 right out of the box. No scripting is necesary. But...my client may not go with 6.0 and they may stay with 5.5. They have very limited resources so even a couple hundred $ to upgrade to 6 might not be possible.
So...I want them to be able to type right in the portal. The reason is, is that when they have serveral files (databases) open at the same time like AUTHORS and TITLES, switching between the files is too clunky for them. It is just not going to work easily. They are doing that now and making too many mistakes. More training in FM Pro may not help much. SO...I hope to have them type new records in the portal. Please keep in mind that they are very busy answering phones, running their business, etc. As a developer I want to make things very simple for them. This is the only way things will work out well for them. The concept of switching between files may seem easy for you and I, but that is not going to work for them. Because that is confusing and difficult for them, they hired me. I want to take advantage of a "live" portal. Yes, it's available in Version 6. Is it POSSIBLE in version 5.5 in an EASY way? I've seen scripting for this for 5.5, but you have to click a button, choose the field to change for EVERY field. This will not be smooth enough for a client needs a VERY simple process.
Sorry,
I'm not likely the man for the job here. I don't have 5.5. I can't hardly believe in 5.0 I was able to have live portals and 5.5 does not. I have a solution in 5.0 with portals and I can type in them if I want. This is of course a related database and to have the database be related takes a script to create the related file. The way I did this was to have the script copy my active record id, then navigate to the new database, create new record, paste my copied record id into a f_record id field, then navigate back to the original database and layout. My relationship is based on the my record id and the f_record id. Because this is done with a script, the screen only flickers and now the record exist in the related record, the portal allows me to type in the fields.
Also I would address the navigation difficulty between databases. I do not think it's about FM training. It sounds like you've inherited a project rather than created it from scratch but as the programmer, you need to provide an intuitive user interface that makes sense. A tab interface is user intuitive. The user presses a tab and the underlying script switches to a different database. Because the developer wants a consistant look and feel, this new database looks just like the one the user left, except for the new fields. In other word, the screen layout should be consistant, say with a top row of tabs. Each tab could be switching from one database to another but the user can't really detect that.
If you are lost at all on this concept, download my solution built in 5.0 and play with the tabs to see how the interface feels. On some of the pages you will see portals in action. Fill in any company name and address to get past the registration screen.
I hope this helps.
Marty
I'm not likely the man for the job here. I don't have 5.5. I can't hardly believe in 5.0 I was able to have live portals and 5.5 does not. I have a solution in 5.0 with portals and I can type in them if I want. This is of course a related database and to have the database be related takes a script to create the related file. The way I did this was to have the script copy my active record id, then navigate to the new database, create new record, paste my copied record id into a f_record id field, then navigate back to the original database and layout. My relationship is based on the my record id and the f_record id. Because this is done with a script, the screen only flickers and now the record exist in the related record, the portal allows me to type in the fields.
Also I would address the navigation difficulty between databases. I do not think it's about FM training. It sounds like you've inherited a project rather than created it from scratch but as the programmer, you need to provide an intuitive user interface that makes sense. A tab interface is user intuitive. The user presses a tab and the underlying script switches to a different database. Because the developer wants a consistant look and feel, this new database looks just like the one the user left, except for the new fields. In other word, the screen layout should be consistant, say with a top row of tabs. Each tab could be switching from one database to another but the user can't really detect that.
If you are lost at all on this concept, download my solution built in 5.0 and play with the tabs to see how the interface feels. On some of the pages you will see portals in action. Fill in any company name and address to get past the registration screen.
I hope this helps.
Marty
-
1
- #5
I dio not understnd why you are having this problem.
Adding and changing records in portals is basic to FMP from about V3.
If you've inherited a database, check that the fields in the portal are set to 'data can be entered'.
I find the hardest thing is stopping users from creating portal records.
Cheers,
Paul J.
Adding and changing records in portals is basic to FMP from about V3.
If you've inherited a database, check that the fields in the portal are set to 'data can be entered'.
I find the hardest thing is stopping users from creating portal records.
Cheers,
Paul J.
- Thread starter
- #6
YYou are all correct! I can type data right into the portal.
I have a CONTACTS database with a portal for DONATIONS. Now, let's say I create a new record in the portal. How do I get the ContactID in the portal to automatically reflect the ContactID of the record I am on (the contactID of the reord in Contacts I am viewing?
I have a CONTACTS database with a portal for DONATIONS. Now, let's say I create a new record in the portal. How do I get the ContactID in the portal to automatically reflect the ContactID of the record I am on (the contactID of the reord in Contacts I am viewing?
- Status
Similar threads
- Locked
- Question
- Locked
- Question