1 2 Previous Next 15 Replies Latest reply on Jul 6, 2011 8:09 AM by philmodjunk

    Very simple image database.  How best to do it?

    GFS

      Title

      Very simple image database.  How best to do it?

      Post

      I posted a couple of other questions ... but really I'm amazed at how much trouble I'm having doing this.  True I hardly use FM these days ... but still.

      This is what I want to do :

      I'm judging a photo competition and want to build a simple databse for voting/counting votes.

      There will be 24 images in 4 rows of 6.  I want this layout to reflect A3 prints we will be using.

      I want to be able to :

      1/ Click an image to increase its vote count (option-click to decrease)

      2/ Have the images show a red surround when within the 5 highest counts (conditional formatting)

      3/ Have a field sitting over them, to obscure them with red when they have been eliminated from the voting.

      That's all!!

      What would be the best way to do this?

      I'm having trouble with using portals and getting the layout 4x6 ... or ... avoiding having 24 scripts and getting a field (formatted as a button) to do the voting with.

        • 1. Re: Very simple image database.  How best to do it?
          philmodjunk

          This isn't really a "very simple" database once you've added the "cross tab" style 4 x 6 display of images.

          Assuming you have a table to store your images with one image to each record and assuming you have a fairly recent version of FileMaker, you can display your images with a layout of records from a related table where you put four single row portals side by side to get a row of four images. To get 6 rows, you could use a form view of 6 rows of such portals or a list view of 6 records. Either way, all the portals are set up to display a record from the same table, but the first one displays 1 row, initial row 1, the second displys 1 row, initial row 2 and so forth to get either 4 images or 24 images displayed.

          There are several options that can be used to control which images show in a given set of 4 or 24 portals. Knowing more about how you plan to present the images for judging might help.

          The container field can be set up as a button so clicking one to log a vote is just a matter of setting it up to run a script to increment your vote count field or variable. A get function, get ( ModifierKeys ) can be used to check and see if the modifier key is down, so the same script can either increment or decrement your count.

          Items 2 and three will likely need a script to support the conditional format settings used to do this. (a field behind the container that is a few pixels larger in each direction can fill with red to produce a "red surround". If you put a Transparent rectangular button over the container field to serve as the voting button, you can specify a red fill color to obscure the image. Just include code in your voting script so that clicking this button for an eliminated image doesn't change the vote count.

          • 2. Re: Very simple image database.  How best to do it?
            GFS

            Phil,

            " This isn't really a "very simple" database once you've added the "cross tab" style 4 x 6 display of images."

            Well you certainly hit the nail on the head there!!

            Thanks so much for the reply and in fact, having initially imagined that this would take an afternoon, I've been at it for days.  It's been a total mind boggler for me, especially as I've worked so little in FM over the last few years.  I've had 3 or 4 separate stabs at it, then come up against brick walls, with specific limitations within FM.  Often techniques that would make the whole process so simple, just can't be done.  Stuff like ... getactivefield doesn't work when it's a button.  Sigh.  I'm using 10 Advanced, which helped hugely with the scripts, being able to see where they were failing.

            In the end, I'm so happy to say that I have built it pretty much along the lines you suggest.  I wish I better understood many functions, but in the end, I kludged it through with variables and 'go to object'.  Tons of them.  It's working, but it's not pretty.  Not pretty because I'm having to activate fields.,

            • 3. Re: Very simple image database.  How best to do it?
              philmodjunk

              In order for a field to be active, the cursor must be in the field. When you set it up as a button, you block the cursor from entering the field. You can, however, pass the name of the field as a script parameter you specify in button setup. That way, your button can know which field was clicked to perform the script.

              Using the portals, I suggested should not require this however. When you click a button inside a portal, that click makes the portal row the active portal row and references to a field in that portal's table will access the data in the record whose row was just clicked by you when you clicked that button.

              • 4. Re: Very simple image database.  How best to do it?
                GFS

                The problem I've had, is that the fields in the image table (1 image per record) are accessed via the portals, but the 'votes' are in the second table (many per record) and I also need to be able to access those from within the script.  I need both ... and have come and gone and changed my mind endlessly about which side to approach from.  As it stands I'm settled on having to go to 'objects' from within in the script in order to 'jump' between tables.  Yes it does seem to all be down to wanting the same physical layout as on the actual, hard copy, prints.

                • 5. Re: Very simple image database.  How best to do it?
                  philmodjunk

                  Surely you could either define the vote count field in the same table as the container field or define a relational link from the image table to your count table? (Since you have a vote count for every image record, it would make sense to me to include a number field as part of the same record.)

                  Either way, you won't need anything but the mouse click to select the record and make it current before your script can get to the correct vote count record and increment/decrement the field. (Use set field, BTW, don't use insert steps for this.)

                  • 6. Re: Very simple image database.  How best to do it?
                    GFS

                    Yes indeed. The 'votes' are in the same table as the images.  So each image has it's own counts in it's own record.  But the votes are also made by the judges and therefore I need to keep them in the 'votes' table and that is also where the flags have to reside, since they are related to the judges, not the images.

                    I found that I had to use SetField By Name, which I have never ever used before (my use goes back to FM2 ... albeit occasional).  In order to do this, I found that I had to name the 'objects' with their full path, table::field then use a variable to extract the name of the field whose contents I needed to access, then use the variable, with the full path, to alter/edit that fields contents, later on in the script, as and where appropriate.

                    • 7. Re: Very simple image database.  How best to do it?
                      philmodjunk

                      You shouldn't need to put the count into two different tables. Incrementing the count field in the images table should suffice here.

                      Your judges data would link to the vote data via a relationship to produce the desired results, but then I don't quite follow what you mean here by "flags".

                      • 8. Re: Very simple image database.  How best to do it?
                        GFS

                        Yes it's the 'flags' that I'm using to facilitate the voting, that are causing the difficulty.  I'm using actual real paper 'stickies' placed onto actual paper prints, to help the judges eliminate images.  I'm replicating this in the databse, so that we can quickly input their votes, via the same metaphor ... stickies.

                        So when I make a vote in the 'Votes' table and the vote is passed through to the images table, via the relationship, I'm also creating a 'sticky' (conditional formatting of a field) which is place over (and outside) the images in the portal, so that when the vote is made, it obscures the image.  These 'stickies' are in fact a record of the votes made by each judge.  One record per judge per round of voting.

                        • 9. Re: Very simple image database.  How best to do it?
                          philmodjunk

                          Still don't see why you'd need set field by name to make that happen. You can log the ID of the current judge in a global field. Your "vote click" can enter Image Id's in that judge's related record (as controlled by by the global field). Then your conditional format expressions can compare the ID of the portal record to the information in this judges record to determine whether or not to hide the image.

                          The images to "hide" can even be stored in a global variable that lists the image Id's of all images selected to be hidden.

                          • 10. Re: Very simple image database.  How best to do it?
                            GFS

                            Hmm ... yes, that is what I should have done.  It's working now, but if I have time (judging is on Monday) I'll perhaps try and fix it (just for fun!)

                            Thanks for the help Phil.

                            • 11. Re: Very simple image database.  How best to do it?
                              GFS

                              Purely out of curiosity ... I toyed with the idea of using 3 tables ; images, votes, judges.  Do you think that would have been a better methodolgy?

                              • 12. Re: Very simple image database.  How best to do it?
                                philmodjunk

                                Since votes are a count specific to each image, from here, I don't see any advantage to putting the votes in a table separate from images.

                                • 13. Re: Very simple image database.  How best to do it?
                                  GFS

                                  Thanks Phil,

                                  I came to the same conclusion.  The difference here between you and I though, is that I walked around my studio at least 30 times, then tried it anyway, before deciding it wasn't the best way. :)

                                  • 14. Re: Very simple image database.  How best to do it?
                                    GFS

                                    Phil,

                                    one last question if I may.

                                    When I was using the SetField by Name script step (which I've never used before) I was unable to use a variable to set the contents. I could use a variable to set the field name (object name must include table::field) but I couldn't use a variable to access the contents of a field (a field I had created a variable for) for the calulated result . Is there anything specific that would make that work?  Is it a syntax thing or does it just not work?  (I also noticed that in both of these dialogs, it is marked at the bottom that the result must be text and yet I found that numbers worked too, resulting in correct calculations) (10 Advanced)

                                    1 2 Previous Next