3 Replies Latest reply on Nov 12, 2013 11:13 PM by mbraendle

    WebViewer fun (and question)




      in the attachment, you find a Five-in-Row (or Japanese: Gomoku) game I had made with FileMaker and the WebViewer.

      It was used as a demo at German FileMaker Konferenz 2013 to show how one can implement pattern matching using n-grams.

      It is still unfinished. Currently, it recognizes which player wins (i.e. has 5 stones in a row, horizontal, vertical or diagonal), but any intermediate pattern (e.g. two intersecting 3-rows) can be defined as well for move analysis.


      Now the question: There is small problem with the WebViewer for which I have not found the cause even by tracking with Script Debugger.


      If you open the file and start a new game, then place a stone on a line intersection, the WebViewer resets after the first move and forgets about it. So you get two black stones as move 1 and 2 and with move 2 black-white alternation begins.

      If you start a new game again (using New game button), this does not happen and one has correct black-white alternation starting with move 1.


      I assume it is some sort of timing problem. But maybe I just have overlooked something simple.

        • 1. Re: WebViewer fun (and question)

          Hi Martin,


          Your post intrigued me, and I wound up playing with the attached file much longer than I expected -- just to see if I could gain some insight into the symptom you described.


          I have not got any solid theory, though I agree with you that a timing problem seems likely.  One extra observation that I can add is that, even if I closed the file, as long as I left FMPA running, when I reopened the file and started a new game, the moves would be properly retained provided I had run at least one new game before closing the file.


          Something that I learned from studying the file in action was about how Safari appears to cache javascript window properties so that upon navigating back to a page, global javascript vars are still in memory (with their previous values!) and ready to be used.  I had no idea that Safari did this -- I know that other browsers do not, and I was surprised that any browser would.  The thing is, however, this behavior seems to only happen after the first page load and navigation forward (unless a game has already been played).  To me, this really suggests that a cached resource loads very quickly, and therefore populates all of its javascript vars in time for whatever sort of navigation "snapshot" of the page takes place.  An uncached page does not.  But this is nothing that I can presently formulate into a good testable theory -- just musing on my part.


          My last comments are simply to compliment you on a great looking file and a really fun concept that you are working on, and to say thanks for posting it.  I know that you have posted information about Processing.js before, and, though I was intrigued, I never took a look.  This time, I pulled apart everything, and read/perused the .pde source file, as well as the processing.js file.  Thanks to your post, the little bit of hands on investigation I did left me with a much better sense of how this must be a fun and productive environment for doing certain types of tasks in the webviewer.  I can see why you like it.  Thank you for sharing it here.


          Good luck with this!  My guess is that there must be some sort of lesser-elegant workaround that can be done to just force the code to "pre-load" before starting a game, but it would be nice to actually get down to the specifics of what is going wrong...


          Best regards,



          1 of 1 people found this helpful
          • 2. Re: WebViewer fun (and question)

            And of course the first-run would be different because the variable has either not been set or is empty.


            (sorry for stating the obvious)


            - Lyndsay

            • 3. Re: WebViewer fun (and question)

              Thanks Steve for your pointers.


              I think I have found the reason.


              In the Gomoku.pde Processing code, there is line 405 which calls callBackToFM(move_color,x_pressed,y_pressed) upon mouse click.


              This JavaScript function is defined in index.html on line 45.


              After the function had been called, program control should go back to the calling Processing code and Processing should continue to draw the board and the moves. This can be investigated by uncommenting line 406.


              But what happens on the first (and subsequent) call of  callBackToFM, that this function will load a new page via the JavaScript document.location call. Which means that the Processing code isn't available anymore in the web viewer and the re-entry point is unknown. So no hand over of control. It seems that the compiled Processing code isn't cached at the first call. Only after the Back-function of the web viewer has been called twice re-entry seems to work.


              I have now slightly adapted the Processing code and the FileMaker scripts so that the Back function of the web viewer isn't used anymore, but the Web viewer is always reset upon a move. All the moves that have been played already are passed via game.xml to Processing, which redraws them from scratch.


              In the attachment, you find the new version (including a splash screen with a few explanations).


              While this works now, I can think about adding more patters and implementing a game engine (so that FileMaker can play against a human).






              Message was edited by: MartinBraendle