Markup User Interface Ideas

Really nice jpbro. :)

Updated with new Progress widget. I tried to do a reasonable approximation of the CJ progress bar in Office2007 mode.

Thanks Mark.

I've got an idea that would be nice to implement for the Progress widget, but I was hoping somebody with graphics/colour blending experience could help me out.

It would be cool if we could pass a colour (#xxxxxx or Long) and the widget would base its gradient values on that colour. This would make it easy to change the colour of the progress bar (for example, if there was an error in processing, you could change the colour to red and the gradients would be updated accordingly).

The standard "green" progress bar uses the folowing 5 gradients, with each colour being a gradient stop from left to right:

Top 1px Gradient        #d9e5c7    #d7e4c4    #ffffff
Next 1px Gradient        #b1ca89    #acc781    #edfdd0
Top Upper-quarter gradient    #9fbe6f    #ace05f    #e5fcbc
Bottom upper-quarter gradient    #8eb355    #a0dd43    #e5fcbc
Bottom half gradient        #69922b    #88c726    #cce49f

The average colour for the entire "green" portion of the progress bar is #99c753. What would be great is if a user could pass the average colour, and the rest of the gradient stops (as listed above) would be computed automatically.

So, is there anybody out there who has some ideas on how this could be accomplished?


Here's a blowup of the progress gradient if it helps:

Thanks Mark, unfortunately I am only an ActiveX subscriber (no source)

No - I don't find it - may be my download was older?

Hi Jason,

jpbro wrote: I've got an idea that would be nice to implement for the Progress widget, but I was hoping somebody with graphics/colour blending experience could help me out. It would be cool if we could pass a colour (#xxxxxx or Long) and the widget would base its gradient values on that colour. This would make it easy to change the colour of the progress bar (for example, if there was an error in processing, you could change the colour to red and the gradients would be updated accordingly). The standard "green" progress bar uses the folowing 5 gradients, with each colour being a gradient stop from left to right: Top 1px Gradient        #d9e5c7    #d7e4c4    #ffffff Next 1px Gradient        #b1ca89    #acc781    #edfdd0 Top Upper-quarter gradient    #9fbe6f    #ace05f    #e5fcbc Bottom upper-quarter gradient    #8eb355    #a0dd43    #e5fcbc Bottom half gradient        #69922b    #88c726    #cce49f The average colour for the entire "green" portion of the progress bar is #99c753. What would be great is if a user could pass the average colour, and the rest of the gradient stops (as listed above) would be computed automatically. So, is there anybody out there who has some ideas on how this could be accomplished? Here's a blowup of the progress gradient if it helps:

Things become clearer in HSL color space:

As HSL
======
Top 1px Gradient                      84,13,90      84,14,89         0,0,100
Next 1px Gradient                  83,32,79         83,35,78         81,18,99
Top Upper-quarter gradient              84,42,75         84,58,88         82,25,99
Bottom upper-quarter gradient         84,53,70         84,70,87         82,25,99
Bottom half gradient                  84,71,57         83,81,78         81,30,89
Avg                         84,58,78

Simplified HSL
==============
Top 1px Gradient                      84,13,90      84,14,89         0,0,100
Next 1px Gradient                  84,32,79         84,35,78         84,18,99
Top Upper-quarter gradient              84,42,75         84,58,88         84,25,99
Bottom upper-quarter gradient         84,53,70         84,70,87         84,25,99
Bottom half gradient                  84,71,57         84,81,78         84,30,89
Avg                         84,58,78



See
https://forum.codejock.com/forum_posts.asp?TID=15126&PID=52828#52828

Hi Jason,

Okay, I see the picture now :)

I'll see what I can do!

Re grayscale progress bar:



Here's new version of xamlBar function from CUiProgress class. Now handles grayscale colors.


Private Function xamlBar() As String
   Dim lo_BaseColor                               As CColor
   Dim la_GradientColors(14)                      As CColor
   Dim lo_Saturation As Long
    

   ' Special thanks to ijwelch from the Codejock forum for this code
   ' to dynamically calculate progress bar gradient stop colors
   ' based on a single base color
   Set lo_BaseColor = New CColor
   lo_BaseColor.OLEColor = m_BaseColor
   If lo_BaseColor.Luminance > 78 Then lo_BaseColor.Luminance = 78
   If lo_BaseColor.Luminance < 21 Then lo_BaseColor.Luminance = 21

    'handle greyscale values
    If lo_BaseColor.Saturation = 0 Then     'it's grayscale
        lo_Saturation = -100    'this will force saturation calculations below to result in 0
    Else
        If lo_BaseColor.Saturation > 78 Then lo_BaseColor.Saturation = 78
        If lo_BaseColor.Saturation < 45 Then lo_BaseColor.Saturation = 45
        lo_Saturation = lo_BaseColor.Saturation
    End If
   'init colors
   
    Set la_GradientColors(0) = New CColor
    la_GradientColors(0).FromHSL lo_BaseColor.Hue, lo_Saturation - 45, lo_BaseColor.Luminance + 12
    Set la_GradientColors(1) = New CColor
    la_GradientColors(1).FromHSL lo_BaseColor.Hue, lo_Saturation - 44, lo_BaseColor.Luminance + 11
    Set la_GradientColors(2) = New CColor
    la_GradientColors(2).FromHSL lo_BaseColor.Hue, 0, lo_BaseColor.Luminance + 22
    Set la_GradientColors(3) = New CColor
    la_GradientColors(3).FromHSL lo_BaseColor.Hue, lo_Saturation - 26, lo_BaseColor.Luminance + 1
    Set la_GradientColors(4) = New CColor
    la_GradientColors(4).FromHSL lo_BaseColor.Hue, lo_Saturation - 23, lo_BaseColor.Luminance + 1
    Set la_GradientColors(5) = New CColor
    la_GradientColors(5).FromHSL lo_BaseColor.Hue, lo_Saturation - 40, lo_BaseColor.Luminance + 21
    Set la_GradientColors(6) = New CColor
    la_GradientColors(6).FromHSL lo_BaseColor.Hue, lo_Saturation - 16, lo_BaseColor.Luminance - 3
    Set la_GradientColors(7) = New CColor
    la_GradientColors(7).FromHSL lo_BaseColor.Hue, lo_Saturation, lo_BaseColor.Luminance + 10
    Set la_GradientColors(8) = New CColor
    la_GradientColors(8).FromHSL lo_BaseColor.Hue, lo_Saturation - 33, lo_BaseColor.Luminance + 21
    Set la_GradientColors(9) = New CColor
    la_GradientColors(9).FromHSL lo_BaseColor.Hue, lo_Saturation - 5, lo_BaseColor.Luminance - 8
    Set la_GradientColors(10) = New CColor
    la_GradientColors(10).FromHSL lo_BaseColor.Hue, lo_Saturation + 12, lo_BaseColor.Luminance + 9
    Set la_GradientColors(11) = New CColor
    la_GradientColors(11).FromHSL lo_BaseColor.Hue, lo_Saturation - 33, lo_BaseColor.Luminance + 21
    Set la_GradientColors(12) = New CColor
    la_GradientColors(12).FromHSL lo_BaseColor.Hue, lo_Saturation + 13, lo_BaseColor.Luminance - 21
    Set la_GradientColors(13) = New CColor
    la_GradientColors(13).FromHSL lo_BaseColor.Hue, lo_Saturation + 23, lo_BaseColor.Luminance
    Set la_GradientColors(14) = New CColor
    la_GradientColors(14).FromHSL lo_BaseColor.Hue, lo_Saturation - 28, lo_BaseColor.Luminance + 11
    Set lo_BaseColor = Nothing
    
   xamlBar = "<StackPanel Orientation='Vertical' HorizontalAlignment='Left'>"
   xamlBar = xamlBar & xamlBarChunk(1, la_GradientColors(0).HTMLColor, la_GradientColors(1).HTMLColor, la_GradientColors(2).HTMLColor)
   xamlBar = xamlBar & xamlBarChunk(1, la_GradientColors(3).HTMLColor, la_GradientColors(4).HTMLColor, la_GradientColors(5).HTMLColor)
   xamlBar = xamlBar & xamlBarChunk(m_BarTopMiddleHeightsPx, la_GradientColors(6).HTMLColor, la_GradientColors(7).HTMLColor, la_GradientColors(8).HTMLColor)
   xamlBar = xamlBar & xamlBarChunk(m_BarTopMiddleHeightsPx, la_GradientColors(9).HTMLColor, la_GradientColors(10).HTMLColor, la_GradientColors(11).HTMLColor)
   xamlBar = xamlBar & xamlBarChunk(m_BarBottomHeightPx, la_GradientColors(12).HTMLColor, la_GradientColors(13).HTMLColor, la_GradientColors(14).HTMLColor)
   xamlBar = xamlBar & "</StackPanel>"
End Function

For some reason, I can't edit my top post...so I'll post the latest source here:

uploads/20090908_230103_RcMarkupUI.zip

Screenshot:

Very cool Ian, thanks a lot! I will try and get your code added to the demo today!

Unfortunately, I can't edit the top post anymore, so I will be posting updates as they arrive in new posts.

This latest update includes Ian's (ijwelch) cool new Sparkline widget. Here's a screenshot of all the current features:



Here's the latest source:

uploads/20090910_105227_RcMarkupUI.zip

Enjoy!

Okay, I've put together a new sample, with some bug fixes, efficiency improvements and a slightly different approach:

1. I'm caching the markup strings as much as possible to be more efficient.
2. I'm using the vbAccelerator String Builder class instead of string concatenation for more efficiency (unfortunately at the expense of some readability)
   
3. I'm now storing a IReportMarkupUI class in each ITEM instead of a single class at the column level. This will lead to more memory usage, but should make it easier to use (especially when you get into progress bar markers and changing Sparkline values, etc...)
4. The Progress widget now properly handles being in a resizable column.
5. Added some more comments to hopefully make things clearer.

I've also attempted to animate the Sparkline widget using a timer. This works, but even with all of the efficiency improvements, interaction with other widgets (e.g. clicking the Switch widget) becomes fairly unresponsive while the timer is running. It often takes 2 clicks to get the value to change. I would be very interested in any ideas on how to improve the efficiency in this area so that the responsiveness stays high. Maybe we need the ability to control RC Redrawing at a finer level? Say a LockRedraw property and RedrawRecord and RedrawRecordItem methods?

I've just had a thought that perhaps I can turn off custom drawing at key moments and maybe that will speed things up...I'll give it a try.

In any case, here's the latest screenshot:



And here's the latest source:

uploads/20090910_173528_RcMarkupUI.zip

Hi Jason and Ian,

1. In sparkline class I get lots of errors <divided by zero errors> in pCalcPoints where some margin is calculated ???
2. Sometimes when you start timer and will start changing values the markup "jumps" to other values. I don't know why it happens but I noticed it several times
3. I would like to add a gradient background (for all charting widgets) and some lines as well (as with MS TaskManager CPU history) I added some markup and it shows OK. But if I want to show progressbar and chart next to each other it doesn't look that nice:   Would be nice if both heights be the same

 

   

It would be nice is someone from Codejock could comment on the responsiveness issues (when clicking items) with the demo app. It seems that the more markup cells that we add, the worse things get (even without animation).

I've tried to optimize the code as much as possible through caching, marking classes as dirty (so updates only occur when changes have been made) and by using a high speed string builder class, but it still seems that markup cells only respond to mouse events every couple of clicks now (not to mention the mouse icon keeps reverting to the default arrow instead of staying as the Hand icon when clicking on markup ui elements). I can only guess that this is because we are adding more and more Markup UI elements to the ReportControl.

Some questions:

1. Is BeforeDrawRow firing too often/unnecessarily? My code does attempt to catch some unnecessary firings (e.g. when Width/Height of ReportItem is 0 pixels, why does it fire then?). If it is firing unnecessarily, can this code be optimized in CJ source to only fire when absolutely necessary?
2. Maybe we need the ability to be able to redraw a single ReportItem instead of having to call Redraw for the whole ReportControl? That way, if only one item has changed we aren't wasting resources redrawing the whole control. Or is there already a better option for redrawing after markup updates?
   
3. Why are the MouseLeftButtonDown and MouseLeftButtonUp markup events becoming completely unresponsive at times? Even with a click sometimes the corresponding sub in the VB6 code aren't being fired. Is this because the markup context is being destroyed and rebuilt during Redraw or something? Does it make sense to somehow cache clicks so that when the markup context is recreated, the clicks get sent? A short delay is better than no effect at all in my opinion.
4. Is it possible to add MarkupContext and MarkupUiElement classes to the ReportControl & ReportControlItems respectively so we can use the (presumably faster) class approach to markup programming (like the MarkupLabel) instead of the slow and painful string approach? This would also allow for completely reusable code between those two controls. In fact, while I'm dreaming, why not add MarkupContext/UiElement to all controls that support markup? It is a vastly superior method (again, in my opinion).

I must say that it is bothering me that Markup for the RC and MarkupLabel hasn't seemed to be getting any further enhancements in a long time. I think it is easily one of the best features of your products (if not the best), as it opens up so many new possibilities for our software. I think the work that Ian and I have done on the RC UI widgets demonstrates just how much potential there is in this area.

I would be interested in hearing what other CJ customers think of the Markup features, because maybe I am alone in this thought (which would explain why markup is being largely ignored lately, or it least why it is not being developed to its full potential).

Thanks in advance for any comments on these issues.

Hi Aaron, the divide by zero problem can be fixed by replacing the offending line with this code:

If sRange = 0 Or (dValues(i) - sMin) = 0 Then          p_Points(i).y = m_HeightPx       Else          p_Points(i).y = m_HeightPx / sRange * (dValues(i) - sMin)       End If

As for the "jumping" problem, I believe that this is by design. It appears that the Sparkline widget dynamically adjusts the display to accomodate the min/max value. So when everything is the same value, you get a flat centered line, but as soon as other values start being introduced to the array of values, the Sparkline will calculate the best fit for the maximum value, and in the case of suddenly appearing negative values, the zero line will even be bumped up to the middle of the chart. This ensures that all values are always optimally visible. It should be possible to add HardMin and HardMax properties though and skip the dynamic calculations. This could be useful where you know you values will always be within a range of numbers and you want to ensure that the chart scale always remains the same.

Lastly, if you play with the margins for your Border tag and adjust the Y1/Y2 properties for your lines, you should be able to get the background image to appear at the same height as the progress bar.  Don't use m_HeightPx + 20, because that would likely move the bottom of your grid outside the bottom of the RC row. I haven't had time to mess around with this too much, but I will try to get to it later.

KILLED LONG CODE BLOCK - NEW UPDATE COMING SOON!

That chart background looks good. Nice one.

Anyone have any ideas for improvements or new widgets?

Hi Aaron, couple of things:

1) What's not working about them? Are you getting errors? They seem to be working here.
2) What lines did you comment out to get things working?
3) Were you using different colours than the ones in the demo, or a different number of stops? Just wondering if the problem lies there.

Regarding the problems you were having with the sparkline, the latest source should have fixed the divide by zero errors, are you still getting them?

Thanks...

Hi Mark,

Are you sure that you have the latest code (my most recent post with a link- unfortunately I can no longer add new file attachments or images to the top post)? Same problem in the EXE? Did you make any modifications to the code?

I've just re-downloaded and all of the sparklines are being drawn in source and EXE.

Strange...I'm now using the latest 13.2 beta (I think it's the latest) and I am noticing some strange problems.

The demo seems to work fine at startup, and if I resize the form, everything works as expected. If I then re-order columns or re-size columns or even just click the grid and then resize the form, then I get the raw markup strings. I'm reasonably certain this wasn't happening before, but I will have to do more checking to see if the problem is with the markup control or with my markup strings. I'll get back ASAP.

Okay, there definitely seems to be a problem with the ReportControl (13.2).

If you click a Markup item that has an event associated with it, you only get 1 click before markup gets disabled. If your markup string is static, then the markup will continue to be rendered, but it will be unresponsive. If your markup is dynamic, then you will end up with raw markup strings.

Put a ReportControl (ReportControl1) on a form with this code to demonstrate the problem:

Option Explicit Private Sub Form_Load()    With Me.ReportControl1       .EnableMarkup = True          .MarkupContext.SetHandler Me             .SetCustomDraw xtpCustomBeforeDrawRow          .Columns.Add 0, "Test", 100, False       .Columns.Add 1, "Test", 100, False       .AutoColumnSizing = True             Dim i As Long             For i = 1 To 3          With .Records.Add             With .AddItem("1")                .Caption = "<Border Cursor='Hand' MouseLeftButtonDown='LeftMouseDown' Background='Blue'><TextBlock Text='Static'/></Border>"             End With                      With .AddItem("2")                .Caption = "<Border Cursor='Hand' MouseLeftButtonDown='LeftMouseDown' Background='Blue'><TextBlock Text='Dynamic " & Me.Width & "'/></Border>"             End With          End With       Next i             .Populate    End With End Sub    Private Sub Form_Resize()    Me.ReportControl1.Move 0, 0, Me.ScaleWidth, Me.ScaleHeight End Sub Private Sub ReportControl1_BeforeDrawRow(ByVal Row As XtremeReportControl.IReportRow, ByVal Item As XtremeReportControl.IReportRecordItem, ByVal Metrics As XtremeReportControl.IReportRecordItemMetrics)    If Item.Index = 1 Then       ' Dynamic column       Item.Caption = "<Border Cursor='Hand' MouseLeftButtonDown='LeftMouseDown' Background='Blue'><TextBlock Text='" & Me.Width & "'/></Border>"    End If End Sub Public Sub LeftMouseDown(Reserved1 As Object, Reserved2 As Object)    ' Only fires once and then markup is disabled    Debug.Print "MOUSE DOWN " & Rnd End Sub

If you click a static column,  the markup will become unresponsive after the first click. If you then resize the form, the dynamic column will show raw markup strings.

This definitely was not a problem with an earlier beta.

Hi Mark, thanks for the catch...I will take a look at that problem once the disabled markup problem is fixed (or perhaps Ian can figure it out easier since it is his code).

Okay, well its related to something, that was just a guess since I only see problem in the latest 13.2 that I have. Did you try the small test case code that I posted?

Weird clipboard or browser malfunction? Anyway, here's the project:

uploads/20090916_142432_RcMarkupDisable.zip

Doesn't work for me. I've download the OCX at the link provided, renamed, re-registered - used both your sample and mine, same problem as described.

There is still a possibility that the problem is with my OCX, but it is difficult to tell 100% what version I am running. The About screen show 13.2, but without a revision # or date on that screen, how do I know 100%? I wish you guys would put a build number or show the file date and time on the About window, it would save a lot of headaches when beta testing.

So it looks like I am up-to-date, but I still have the problem. Here's the result after a single click:

I don't understand what the problem is - is it that I have an older Markup OCX? I didn't realize that the RC and the Markup OCX were dependent on each other? Or do you have a more recent RC version with newer internal markup that hasn't been built yet?

Still broken for me. I tried going back to an older 13.2 (doesn't have .PaintManager.GrayIfDisable property) and the code works as expected. I then retry the latest OCX (Sep16 @ 4:21PM) from the link provided above, and I get raw markup. I've tried this on Vista and Win2K, same problem.

Hi,

1. Once a different row is selected and resize 1 column manually all Markup is broken except the attribute and switch widget column.
2. Once a different row is selected and resize form (same thing)
3. (another thing I noticed) I can't (for some reason) resize column larger than ??? only clicking a columnsplitter will show line on different place then column (see image)

I debug it and found that effect related to enable - disable markup. I see trace of Enable Markup after X-icon disparead but I guess inside item markup context is not valid now as it related to obsolete markup context of control - and control created new one!

I think we should forget about EnableMarkup function - looks like it not designed to toggle.

Please get updated ocx from the same link NOW and confirm the speed and other functional features

Sorry, I missed your post. Will test now.

Okay, I now understand why the BeforeDrawRow event was firing 6 times on a single mouse down - it fires for each visible row and column, and my sample had 2 columns and 3 rows.

Is there a way to optimize the BeforeDrawRow event to only fire for the single cell that was clicked? Or is this a bad idea? I could image that maybe it needs to fire for a whole row if the selection is changing...but it seems excessive to always fire for all visible cells in all circumstances.

I'll attach a very simple markup project that has poor responsiveness (often needs 2 clicks to get a response). This markup is about as basic as it gets, so really it seems like markup events are unusable in the real-world if this is the best performance we can get:

uploads/20090918_222207_RcMarkupClickSl.zip

Well we would like to have our cake and eat it too ;)

Kidding aside, I'm only wondering if it everything is working as fast as it can. In my RcMarkupUI demo, I am caching strings, and short-circuiting BeforeDrawRow when no changes have been made to the underlying markup (as you suggest) in order to try and speed things up, but it is still slow to respond to click events. In the very simple demo I posted above, there is really very little going on markup-wise, and it is still slow to respond.

So, if this is indeed as fast as it gets, that's good to know, but it does mean that interactive markup is not really going to be useful in the real world. That's fine if that's the case, I am just wondering if this is the case, or if there are inefficiencies in the current design that can be improved. You mention that BeforeDrawRow is doing its job, but I'm arguing that it is over-doing its job - why should BeforeDrawRow fire for rows that haven't been affected by anything? If a user clicks the mouse down on Row 2, why should BeforeDrawRow fire for all of the other visible rows? Maybe there is a good reason, I don't know, that's why I am asking. If there is no good reason, then maybe this is an area for optimization?

Also, even though you say there is no BeforeDrawCell, BeforeDrawRow sure seems to behave more like BeforeDrawCell than BeforeDrawRow (note that it has Row and Item parameters, which essentially correspond to a cell when combined).

Hi Jason,

Because BeforeDrawRow event fires on MouseDown and MouseUp clicks (I don't know why this is necessary but it does ?!?!) Your clicking on (for example Switch item) are updated in between. Meaning BeforeDrawRow event already updated Switch reportitem but "didn't know" that value of icon had to be changed (value didn't change yet?) Forcing RC redraw will update the switch reportitem. 

Add Me.ReportControl1.Redraw in mo_MarkupEvents_SwitchClicked event. Run project > Now you will see the icon gets updated (if you have a lot of items you will see that items get updated a little slower) but at least it's updated... If you comment the .Redraw the item gets updated if you force RC to fire BeforeDrawRow event > so just using arrow down to select next row will do this. See? Previous row gets updated.

extra info about BeforeDrawRow:

Jason - just potential idea how to cover X-cursor case: we can make public function

 

inside this function will get current cursor HCURSOR hc = GetCursor();

and compare it with loaded X-Cursor handle

 

Before making any markup action app can call this function to check

In such approach we will not toggle enable - disable - we just prevent some actions....

You can try to use this new function on VB level - I exposed this checker BOOL Is_X_Cursor to ocx (code not SVN yet - just testing)

 

I think it can be simple start for you to check such approach

 

This modified ocx with new bool function ReportControl.Is_X_Cursor - uploads/20090919_121425_ReportControl_X.rar

 

No - this is bad idea - markup elements change cursor irrelevant to any report-based OnMouseMove functions

Sorry.

Actually, I just tried enabling drag and drop in my sample, and when dragging columns the Markup cursors are completely ignored by the ReportControl. How is this being achieved, and can it be extended to the column drag cursor?

I'm using the latest version with Is_X_Cursor property available, but it is not relevant to the Drag & Drop case (if that's what you are asking):

See this sample:

uploads/20090919_135837_RcMarkupCursor.zip

It has Drag & Drop enabled, and if you start dragging a row, the markup cursor does not over ride the drag & drop cursor. However, if you try dragging a column header, the markup cursor does override the X cursor. So maybe there is a clue here? How does the D&D cursor remain steady while the X cursor doesn't? Can whatever method D&D is using to maintain its cursor be reproduced by the X cursor code?

Maybe my cold is getting in the way of my thinking, but I don't see how Is_X_Cursor can realistically help on the VB side of things...I would have to continually update markup strings for all visible cells and modify the Cursor property for every tag as far as I can tell, which is really a lot to ask (it certainly appears to be a logistical nightmare). Unless you have a better idea that I haven't thought of, I think the Is_X_Cursor/Mouse tracking hand-off would be best handled directly between the ReportControl and the Markup core. Thanks for trying it out though...

jpbro wrote: Okay, I now understand why the BeforeDrawRow event was firing 6 times on a single mouse down - it fires for each visible row and column, and my sample had 2 columns and 3 rows.

1. MouseDown 15
2. MouseUp 25
3. MouseUp on Switch widget 45 times
4. Select next row with arrow down key 90 (2 rows visible)
5. Select previous row with arrow up 55 (2 rows visible)
6. TAB key 30 times (2 rows visible)
7. Page-Up 45 times (2 rows visible) (understandable! because RC needs to redraw rows)
8. Page-Down 55 times (2 rows visible) (understandable! because RC needs to redraw rows)

mdoubson wrote: Guys - you aways asking about this infinite notifications which definetely slow your app down. BeforeDrawRow do it's job and there is no BeforeDrawCell function and developer want to use fancy individual shape for each cell. Can you improve your respond function to return immedeately if no action need? Still many calls but fast? Is markup scripting language? I think yes - so this is also reason for app to be slow

mdoubson wrote: OK - please post a list of non-needed cases and let other members confirm it because they can have another models and need some notifications you consider as non-needed