I don’t think this is related to this specific custom control but I have never encounter the same problem in any other XOJO code. I think the control has lots of Javascript and it is a little more sluggish getting back and forth from the browser. Because it is a calendar just “clicking around” seems to be logical so clicking dates in rapid succession can easily be accomplished.
I am using Taylor Design’s calendar control and I have some logic and SQL queries that (at least on my Mac) can take 1-2 seconds to complete. I fire the logic when the user clicks a date on the calendar from the DateSelect event. It appears that if the previous logic has not yet completed and I click a second date SOMETIMES I get a strange error when doing one of the SQL queries that says “No Session Object In Context”. This happens right after one of several SQLSelects and I am looking for SQL errors.
rs2 = Session.HCDB.SQLSelect(SQL)
if Session.HCDB.Error = true then
If I do NOT click the calendar control until I visibly see that the logic is complete then it NEVER fails.
I have tried adding a flag as a session property in my logic to keep it from running twice if you click too quickly but it does not seem to work as expected. I check to see if it is set at the beginning of the logic and if it is just exit. If not then set the flag at the beginning and clear it at the end. I even added some System.Debug messages to know when the flag catches two rapid clicks but I never see that message. I really don’t understand why this does not work and maybe I am looking at the wrong problem. I suspect that maybe the browser is sending the click events back to the process maybe almost simultaneously and the flag does not catch the problem.
I have also tried to set the calendar control ENABLED = FALSE until the logic completes but it never gets back to the browser in time to disable the control to stop the second click. It does disable because I can see it but it just takes to long to stop a second click.
I know this is all about timing but I don’t seem to find a way to find a solution.
Does anybody have a suggestion to keep the user from clicking the calendar control multiple times too quickly or keep the logic from running on the subsequent clicks if it is not yet done from the first click?
Thanks.
I’m not sure why the property is failing as a checkpoint because Xojo uses a cooperative threading model. That said, if you need to block code reentry you should use a CriticalSection or a Semaphore. When doing so you need to be careful that they are released regardless of success, failure, or exception.
But a bigger issue is that you’re performing a 1-2 second operation in a control event in the first place. Whether you’re dealing with a Xojo control or a custom one, IMHO an event should complete as quickly as possible. Long operations should spin off into Threads, server side Timers, or client triggered WebTimers.
Like with the property I would think you could just put your long running code in a Thread or Timer and check to see if said object is running when the event comes in. But if you still have trouble with that I would use a CriticalSection or Semaphore in the event handler.
FYI, if this is a project you can send to me, or if you can provide me with a test that reproduces the situation, I can give you code to work around whatever timing/reentry issue you’re hitting.
Daniel,
Thanks for the reply.
I tried a “do it yourself” semaphore technique with a variable but that did not work. It appeared that the multiple clicks fired the server side logic at almost the exact same time as if they were sent to the server at the same time. I think this is surfacing because “clicking around without waiting” seems “normal” on the calendar control. Buttons and other things don’t encourage that behavior.
This will likely execute faster on my server. My MacBook has 8GB of RAM and an SSD but I have noticed some hesitation sometimes. Everything else but a query in XOJO is simply almost “instant”. A little MySQL tuning might be in order. I had a XOJO program that on my Mac would take 5-8 seconds to complete a SQL query and it happened in less than one second on the server. In general I don’t see this in my SQL query tool but only in XOJO.
I have never used a XOJO Semaphore or CriticalSection before. I will look at those. I thought about a timer and just started to code that technique. That actually might be better because clicking a new calendar date does not always need to refresh the highlight selection so I can control that by only setting the “execute on this tick” flag and set the tick to once per second.
If I get totally stuck I will try to create an example for you to look at that will reproduce the problem.
Mark
It looks like using a timer will work. It will take a little more “fine tuning” of the logic but it seems to solve the problem even for rapid clicking around on calendar. I simply set a property flag when a date is clicked to let the timer know on the next one second click to process.
I am going to guess two things are happening. As I said before the calendar control is easy to just “click around” and fire the date selected event rapidly where you probably won’t do that with a button. The calendar control appears to be a noticeably slower than things like buttons although only milliseconds of difference. It appears that this creates a much higher risk of recursion due to rapid clicking while previous clicks are being processed by the javascript in the control.
It is a guess but I suspect if you could click a button control rapidly enough on a slow processing server side function you might get the same error.
I’ve definitely seen issues like this before which leads to my rule that long operations should be handed off to Threads or Timers. Susceptibility certainly could vary based on the JavaScript in the underlying control.