Problem with Adding to TimeBlockList

jku@amstlc.com

I am encountering two issues with adding 'TimeBlocks' to the Schedule Control:

1. Adding random time blocks to the list has caused a 'OpenInsight' is not responding message fairly frequently. Unfortunately, I don't seem to be able to cause this to happen, so I can't report a 'path' to creating this problem.

2. I am adding time blocks to the schedule by using the 'OnScheduleClick' event and then calling a dialog box to collect the information necessary to add to the 'TimeBlockList' property. This is working, to a point. If you add a time block to an entity to the left of an entity that already has a time block, SOMETIMES the schedule will pop duplicate time blocks from other columns into the column to which you are adding a time block and duplicates into other columns as well. I have inspected the 'TimeBlockList' variable that I am maintaining and do not see duplicate instances in that variable. Also, if I close the schedule and then reopen it (which then reads the TimeBlockList variable from a file in which I am maintaining it), the duplicate time blocks are gone.

DonBakke

Jan,

Are you always using the TimeBlockList property when adding new time blocks? Have you tried using the AddTimeBlocks method instead? You may have uncovered a problem with the TimeBlockList property but your description of what you are doing suggests to me that the AddTimeBlocks method would suit your needs better.

jku@amstlc.com

Don: Initially I didn't use the AddTimeBlocks because from the documentation for that Method, it appeared it didn't collect the date as well as the time. In rereading the documentation, I see that the passed array has exactly the same format the as TimeBlockList property, so clearly I misunderstood that. In the meantime, I wrote an external process that maintains the TimeBlockList in a file with the date as the key so that any time changes are made, the file data is updated. This assures me that if the schedule is closed unintentionally I still have the most current list. Obviously I could still maintain this file data with the AddTimeBlocks method, but unless there appears to be a serious degradation in performance because the control has to remove and then replace all the time blocks, I don't quite see the benefit of rewriting that process.

DonBakke

Jan,

I am not expecting you to rewrite your process. If the property is at fault then we will work to address it. However, if you need a workaround in the meantime then perhaps the AddTimeBlocks method will work.

Having said that, there is a best practice approach to using some of the Schedule control's properties that support multiple data points:

• Use properties like TimeBlockList when you want to set multiple objects at once. This allows for optimum performance when several objects need to be added to the Schedule control. This is ideal for setup processes, such as when the software is launched.
  
  
• Use methods like AddTimeBlock when you want to add/remove an object. This allows for optimum flexibility and performance when objects already exist in the Schedule control and you only need to add/remove one object at a time. This is ideal for operations that allows users to make on-demand changes.

If I understand you correctly, you are simply using the TimeBlockList property to handle both types of operations. While the TimeBlockList property should work just fine, it is possible we are seeing a bug when the property is being reset this way.

Quite often these kind of bugs are difficult for us to discover because they tend to only occur under unique circumstances. In these cases we need to lean on our customers for additional help. This leads me to a couple more questions:

1. Do you see OI crashing when you first launch your software and use the TimeBlockList property or does it only seem to happen when you update the property during subsequent operations?
   
2. Would you be willing to update your logic in the OnScheduleClick event to use the AddTimeBlock method instead of updating the TimeBlockList property? I would like to know if this resolves the duplicate timeblock anomaly. This will also help us fix the TimeBlockList property.

DonBakke

For the benefit of anybody following this thread (or future readers looking for help with this issue) I wanted to provide a summary of the resolution. Jan and I took this discussion offline so we could walk through some actual demonstrations of the problem using her system. We have resolved a couple of items and I want to document those here.

We believe both the intermittent OpenInsight crashes and the odd visual anomalies (i.e., time blocks would be duplicated and appear under different entities) were related to the same issue. Specifically, the Schedule control did not properly handle the setting of the same time block value multiple times. This was never discovered during our original tests because (as noted above) the best practice is to use the TimeBlockList property to setup the initial time blocks on the Schedule (e.g., those which were pre-defined in the database) and then to use the AddTimeBlock method to add new time blocks. In theory, no time block would be added to the Schedule control more than once in a single run-time session. However, since Jan was using the TimeBlockList property to add new time blocks, this also re-added pre-existing time blocks (out of necessity, or otherwise they would have been removed.) This exposed a bug in the Schedule control which has now been fixed and will be included in the next release.

During the offline testing session with Jan, she also discovered another issue: The AfterNewApptDrop event would fire after the OnScheduleClick event. This was a problem because the former event is used to create new appointments and the latter event is used to create new time blocks. The intent was to give the user a way to create one or the other using a familiar technique (mouse left click), but since the AfterNewApptDrop event requires a drag motion to distinguish itself, this seemed like a safe design approach.

This exposed a natural conflict that occurs with certain events, similar to how single-click and double-click events can also interfere with one another. Consider the following gotchas:

1. The OnScheduleClick event is triggered when the mouse button is pressed as opposed to when it is released. Since it is actually very difficult to click a mouse button without some amount of movement, this produces both the OnScheduleClick and the AfterNewApptDrop event.
   
   
2. As a secondary consequence to the above situation, even if the user only intended to create a new appointment (i.e, click-and-drag), the immediate pressing of the mouse button would fire the OnScheduleClick event. The developer would have no idea what the user intended and thus would have no choice but to execute the logic (which resulted in adding a time block in Jan's case.)

Double whammy! The moral of the story is that trapping the left click of a button and trapping the left click and drag of a button on the same control to provide different features is not a safe or recommended design choice. In Jan's case, she switched the time block logic to the right click.

This adventure did yield some minor treasure. I proposed to add the detection of the Ctrl, Alt, and Shift keys to the AfterNewApptDrop event in order to provide her with more options (e.g., Left Click Drag for new appointments, Shift+Left Click Drag for new time blocks). As we dug into the code to add this support we discovered that it was already there! It just never got documented. Using the magic of the wiki, the AfterNewApptDrop event was quickly updated to reflect these arguments.