Jump to content

user input in header


macavity
 Share

This topic is 6586 days old. Please don't post here. Open a new topic instead.

Recommended Posts

I know it's theoretically impossible, but it seems so necessary that I thought someone here might have found a better workaround than mine.

Here's the problem:

Users create lists. The contents of the lists will frequently be edited and the lists are repeatedly consulted or printed out. The lists need individual titles that are not stored within the database. The easiest solution would be for the user simply to type the title into the header before printing. No dice, of course.

The workaround I've found is so clumsy that I hope there's a better one:

Scripted: User types info into global field. Information is looped through all found records in list. As the header will show the value of the currently selected record, the info is displayed in the same field placed in header section, wherever the user's cursor may be.

This solution is ugly and counter-intuitive for the user, since he doesn't see where on the page he is typing the information. (I found the example that places the global field under the record in the body. That's a slight improvement - but only slight.

Is there a better way?

Link to comment
Share on other sites

I think you've got answer in the use of a global field - however it's easier than you thought.

I'm assuming you are referring to viewing records in a list view, not value lists.

No looping is necessary with a global field, that's what global fields are all about.

I would show the Global field (do not allow data entry) in the header and select the field as a button that calls a script that gives you a custom dialogue with data enter in the global field.

Pretty easy and intuitive for the user I would think.

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

A more elegant option that requires a bit more work on your part is to create a form layout that uses a portal and realtionships to display the records. It's quite a bit more complicated to design, but you can set it up so that the user enters their find or list criteria and the list automatically filters itself. If you want to go this route, I can get you more information or examples.

Link to comment
Share on other sites

Thanks Bruce. I guess I should have done it with a portal. But for the purpose I thought quick and easy lists would be enough.

Unless I'm misunderstanding you, I don't think a simple global field would do because these lists will be consulted by different people in a network. I don't know how it would be possible to ensure that the same title was seen by all the users, since global fields are stored locally. Furthmore whenever a new list was created using the same script (but different search criteria) the title of the earlier list would be lost. That wouldn't be good, as the earlier search criteria should still produce the earlier list with its title. (Though, come to think of it, that wouldn't be the case even if it were possible to enter date directly into a header field)

Link to comment
Share on other sites

I see. Then I'd add another file for titles only. The use a script too mark each found record in the found list. In the script, I'd use this in the loop:

SetField(Mark, Mark & "P" & RealtionshipToTitles::RecordID")

The "P" being a paragragh return. This will allow multiple marks in the same field so you can recall the list via the realtionship in the Titles file. In the titles file you can do something like, Go To Related Records, show only related records, and then preform a script in the records file to sort and go the right layout for the list.

Now that I know you're wanting to create and save multiple lists, I see that soem sort of loop is the most common way to accomplish this.

Link to comment
Share on other sites

That seems like a better solution in many ways. The only problem I can see is that since the lists will be frequently consulted and often have records added to them, individual records would end up being represented multiple times in the related record of the titles file. I suppose the solution would be to mark the original records as well, and have the script skip them in the loop. Right?

Thanks, again!

Link to comment
Share on other sites

I 6 of one half dozen of the other. For whatever reason, I'd choose to mark the found records with the unique ID of the related title. And - in the loop, use and If "PatternCount(markfield, ListItems::UniqueID)>0" to skip the process of makring the record and move on.

Link to comment
Share on other sites

This topic is 6586 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...

Important Information

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