Results 1 to 5 of 5

Thread: It's not too late to fix the cWebTreeView

Hybrid View

Previous Post Previous Post   Next Post Next Post
  1. #1
    Join Date
    Mar 2009
    Location
    Adelaide, South Australia
    Posts
    477

    Default It's not too late to fix the cWebTreeView

    Since 2013 there have been a number of issues reported with the cWebTreeView. This post applies to 18.2 http://support.dataaccess.com/Forums...t=cWebTreeView and Sture reported the same problem in May 2015.

    I'm now running into the same issue with a cWebTreeView in a WebModalDialog. Clicking on a node returns the data I want and closes the dialog. If the dialog is opened again even after moving around views and despite a Fullrefresh in OnShow, the last item clicked is highlighted. If that item is clicked again, the OnSelect event is not called on the server and a second click is required. The client is clearly responding as shown in the attached images. The first click removes the icon alongside the item but doesn't tell the server. This looks to me like a bug in the .js It is true that if a different node is clicked that will respond immediately, as expected.

    While this is not a deal breaker, it is something we are sharing with the user who has to work out that sometimes a double click is necessary. Not really a good look.

    Ian
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	CategoryList1.JPG 
Views:	239 
Size:	17.4 KB 
ID:	9776   Click image for larger version. 

Name:	CategoryLis2.JPG 
Views:	238 
Size:	17.6 KB 
ID:	9777  
    The most important leg on a three legged stool is the one that's missing.
    Murphy's Law (2)

  2. #2
    Join Date
    Feb 2009
    Location
    The Netherlands
    Posts
    4,674

    Default Re: It's not too late to fix the cWebTreeView

    There are a few things here.

    First of all this pointed to a bug in the Df_Flat_... theme causing the icon to disappear when clicking the selected item again. That is a pure CSS change with a very low risk and this is introduced in 18.1 / 18.2 so that is something we will consider fixing that for 18.2.

    Then there is the OnSelect behavior. The OnSelect is designed to trigger when the selected item changes by user interaction. According to that specification it is actually triggering too often as it sometimes triggers when clicking the selected item. Analyzing the code learns that that actually seems to happen pretty much by accident. Fixing this would make it function according to the spec but most like won’t help you (it also wouldn’t meet the requirements for something to be fixed in this stage of 18.2).

    It seems that what you need an OnItemClick event that is triggered on every click. So that is a feature request for which certainly is too late in the 18.2 cycle.

    What I don’t understand here is why the item is selected when you open the dialog for a second time. By default (certainly in 18.2) the treeview won’t have a selected item. Do you have code that selects the item or are you setting pbOverrideStateOnShow on the dialog?

  3. #3
    Join Date
    Mar 2009
    Location
    Adelaide, South Australia
    Posts
    477

    Default Re: It's not too late to fix the cWebTreeView

    Quote Originally Posted by Harm Wibier View Post
    There are a few things here.

    First of all this pointed to a bug in the Df_Flat_... theme causing the icon to disappear when clicking the selected item again. That is a pure CSS change with a very low risk and this is introduced in 18.1 / 18.2 so that is something we will consider fixing that for 18.2.
    Thanks Harm.

    Then there is the OnSelect behavior. The OnSelect is designed to trigger when the selected item changes by user interaction. According to that specification it is actually triggering too often as it sometimes triggers when clicking the selected item. Analyzing the code learns that that actually seems to happen pretty much by accident. Fixing this would make it function according to the spec but most like won’t help you (it also wouldn’t meet the requirements for something to be fixed in this stage of 18.2).
    You're right, as long as the selected item isn't being cleared the current behavior is better than the spec.

    It seems that what you need an OnItemClick event that is triggered on every click. So that is a feature request for which certainly is too late in the 18.2 cycle.
    I suppose that would overcome this problem but it would be better to fix the actual problem which I am sure is not to spec.

    What I don’t understand here is why the item is selected when you open the dialog for a second time. By default (certainly in 18.2) the treeview won’t have a selected item. Do you have code that selects the item or are you setting pbOverrideStateOnShow on the dialog?
    Nor do I understand why it comes up selected. It is almost as though the dialog is setting there in the background and is simply re-focused when opened a second time. I had pbOverrideStateOnShow set to false but setting it to true makes no difference. I was exiting the dialog by sending OK. I have now tried setting pbServerOnEscape to True and sending Cancel but no difference.

    I'll do a bit more testing.

    Ian
    The most important leg on a three legged stool is the one that's missing.
    Murphy's Law (2)

  4. #4
    Join Date
    Feb 2009
    Location
    The Netherlands
    Posts
    4,674

    Default Re: It's not too late to fix the cWebTreeView

    Can you post a sample demonstrating your issue?

  5. #5
    Join Date
    Mar 2009
    Location
    Adelaide, South Australia
    Posts
    477

    Default Re: It's not too late to fix the cWebTreeView

    Hi Harm,
    Issue resolved and the solution was in the Help (sort of).

    I noticed during testing that FullRefresh was not being called after the initial call to the dialog. The data was all there and simply redisplayed from the cached html as explained below. Although the Help was concerned about security, simply placing the line:
    Send UnloadView hoModalDialog
    as the last line in OnCloseModalDialog causes the FullRefresh to fire each time and there is no selected item. I suggest in a future version DAW should add a WebProperty "pbUnloadDialogAfterSelection" which defaults to True. In the meantime, it might be worthwhile to amend the Help to advise developers to add the line above unless they have a good reason not to.

    Unloading Dialogs for Security
    When a modal dialog is loaded and displayed on the client, a cached copy of the dialog (including sub objects and web property values) will remain even after the modal dialog has been closed. Normally, this does not present a security problem as the logged in user should already have access rights to the dialog in order to load it in the first place.

    A potential security consideration occurs if, after a dialog has been loaded, the current user logs out and a new user, with different access rights, logs in. The safest approach here is to ensure that the entire web application is reloaded whenever a new user tries to log in. This will ensure that all cached data is removed from the client.

    Send NavigateRefresh to the global cWebApp object (ghoWebApp) to reload the entire web application.

    Sometimes you may wish to retain the web application's current state, but remove specific views or dialogs from the client. Send UnloadView to remove a specific view
    or dialog from the client.
    Ian
    The most important leg on a three legged stool is the one that's missing.
    Murphy's Law (2)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •