Script to determine selected portal record?

[spankalee]

FM for some really odd reason does not have a selection list. Not a Pop-Up list, but a multi-line selection list. So I'm trying to imitate this with a portal...

I'd like the user to select an item in the list, then click on a button (not in the portal) and run a script. I need to know which portal record is selected so I can do the right thing. So far I can't figure it out.

Any suggestion?

Thanks,

S

[-Queue-]

You can store the current portal row in a global with Set Field [globanum; Get(PortalRowNumber)] or the id of the currently selected related record using Set Field [gid; relationship::serial] at the start of your script. I think it should work, as long as you don't click out of the portal or Commit Records before the step.

[Vaughan]

From an interface perspective, I'd put the button in each portal row. Makes the process that much more reliable.

[-Queue-]

Agreed. But if you really detest the idea of putting the button in the portal, you can test If [not Get(PortalRowNumber)] and Halt Script at the beginning of your script. So that if no related field is selected, nothing happens.

[spankalee]

Thanks Guys,

I saw the Get(PortalRowNumber) function, but I need to grab the record id, or actually the name of the layout that stored in the record.

It looks like Set Field [gid; relationship::serial] is the direction to go in, but I'm not sure I understand how that works. I'll try it first thing when I get to work.

I use the button on every portal row method in other areas, but it makes sense there and doesn't here. I'm basically building a wizard for some employees to print labels. It needs to be as simple as possible and I want to use the classic wizard next and back buttons. I'm ok with building a more complex script if I can get it to behave correctly.

Thanks,

S

ps and pretty off-topic: I can't believe FM doesn't have a multiple select box. The last few problems I've had with FM have pretty much convinced me to migrate away from it. It's GUI features are inexcusably lacking. No trees, tab panels, flexible layouts. It's incredible really. I also do web app development with MySQL and Cocoon, and I think I'm going to take this project to MySQL next year. The problem has always been deciding what to do the user interface in. As bad as FM is HTML is equally bad, just different. Recently though I've been using XUL and Firefox/Mozilla for some prototyping. It makes up for almost all of HTML's deficiencies. So now I've got to work on migrating the database layer. One thing I do like about FM is calculation fields. In a lot of areas it makes sense to keep the calculations with the database layer, especially if there are relationships based on them. SQL databases don't have calculation fields, so I'm trying to figure out the best way to implement them.

I've been wanting to post that question somewhere here, but don't quite know where. What forum would be appropriate? Asking this through a MySQL group wouldn't be too useful because few of them would understand the FM way and where I'm coming from.

[QuinTech]

It looks like Set Field [gid; relationship::serial] is the direction to go in

Make sure this is the first step after the user clicks the portal row, otherwise you may lose focus.

[continuing off-topic thread]

I can't believe FM doesn't have a multiple select box.

The checkbox doesn't work for you? Or is this a web-specific thing (i must admit, i'm 100% ignorant of FM's web capabilities.)

I think I'm going to take this project to MySQL next year

I suppose that's because MySQL is better for this type of thing! FM is a fantastic workgroup tool, but maybe not the best web tool. Any of the limited web projects i've done have been in PHP & MySQL. Our office is FMP wall-to-wall, top-to-bottom, but it seemed to me it would be easiest to do what we needed with MySQL instead. Just be happy that you have both tools at your disposal to use in appropriate situations.

J

[spankalee]

Make sure this is the first step after the user clicks the portal row, otherwise you may lose focus.

gotcha, thanks.

[continuing off-topic thread]

I can't believe FM doesn't have a multiple select box.

The checkbox doesn't work for you? Or is this a web-specific thing (i must admit, i'm 100% ignorant of FM's web capabilities.)

This is a desktop app, not a web app. A guess regular pop-up list would work for me, but I'm just growing tired of always doing things different than I want to because FM doesn't have a certain feature. I'd like to use a listbox and it's available is just about any other GUI environment. For this application I think it'll increase the usability quite a bit, which is why I'm willing to go through the trouble of simulating one.

I think I'm going to take this project to MySQL next year

I suppose that's because MySQL is better for this type of thing!

<snip>

Just be happy that you have both tools at your disposal to use in appropriate situations.

[QuinTech]

A guess regular pop-up list would work for me

And how about the CHECKBOX?

Sorry, don't mean to shout , but to me the term "listbox" sounds like the exact thing FM calls a checkbox. Allows you to select multiple options at once. Have you used this before?

[spankalee]

And how about the CHECKBOX?

Sorry, don't mean to shout , but to me the term "listbox" sounds like the exact thing FM calls a checkbox. Allows you to select multiple options at once. Have you used this before?

That's ok Quin, understood. no problem...

A checkbox would be ok if I knew the number of elements was going to stay the same, but if the value list has more element than the checkbox can display it doesn't scroll. That's the biggest problem. For this application I also don't need to be able to select multiple items.

Maybe you mean putting a checkbox in the portal? I thought of this, since I use that method in other areas. But it's just not elegant; it requires more clicks than are necessary and it would also be possible to select more than one list item, which I don't want.

The basic idea is that they select a label type from the list, choose from a few options, enter a list of product codes and the number of labels per code to print and then click the "make labels" button. This part of the system is not going to be used by the salespeople, book-keeper, the owners, or people with decent computer skills. It's for the guys who make our samples. Up till now the office people made the sample stickers for them, and I want to make everything as simple as possible.

It's not really the end of the world if they had to check a box, or choose from a drop-down list, it's just not the way I would prefer to do it. In just about any other GUI tool/environment this would be simple - probably one of the first things you learn how to do actually. In FM it requires either compromises or tricks. I'm just growing tired of that, that's all. On one hand it's a neat challenge sometimes to figure out how to do something that FM wasn't intended to do, but on the other hand why waste my time re-inventing the wheel? It's almost 2005 and FileMaker just went through a major rewrite - how come the GUI features are at a standstill? Is setting the initial portal row all we get? When HTML can give your GUI a run for it's money you're in serious trouble. Don't even get me started on simulating tab boxes - that's just insane. I get seriously pissed if I ever have to change something in the GUI and it requires me to change 5 to 15 to who knows how many layouts.

I know that FM makes a lot of things easier, but it makes some things that are usually easy incredibly and inextricably tough. The amount of time I save with easy installations, database creation and certain GUI layouts is wasted on complex tricks. To top it off they want a pretty good grip of cash for each client and especially for the server.

Well, I have the portal-as-listbox basically working. Thanks for the help. I'm interested in discussing the general topic of FM's features and of migrating from and to SQL solutions, but this probably isn't the right place. Which forum should I take this too?

-s

[QuinTech]

I think i see what you're trying to do... is the attached file an example? Maybe this is what you've already done and found lacking, but from your descriptions of the task at hand, i don't see any real negatives. It seems to work just as you want it to: single selection, followed by selection of options, followed by an "execute command" button.

spankalee.zip