How to pass ListView keyevents to ListView.header



  • Hi,

    I have a ListView attached its header with TextInput, as text field should scroll along with list(should not stick to the screen).

    The requirement here is regardless of focus all key presses should received by text field.

    I am planning to pass/forward all the key press events to the text input. But I could not pass/forward(Keys.forwardTo) events to header, as header is a Component, not an object.

    @ListView {
    id: list
    focus: true

        header:  InputField { // Contains TextInput
            id: edit
        }
        //Keys.forwardTo : [edit] : // error
    

    }@

    Can anyone help me to resolve this issue.

    Thanks in advance.



  • have you tried
    @
    Keys.forwardTo:header
    @

    ?



  • Hi Kxyu,

    Thanks for quick help,

    yes i tried this(Keys.forwardTo:header). It was crashing the application, And i even understand the reason for crash, ListView.hearder is a QML component not an item, but Keys.forwardTo requires list of items.



  • this forwardTo thing seems to have a ton of bugs. all logically correct solutions crash qmlviewer
    but I've found a tricky one for you). here it is

    @
    Item{
    clip:true //this is needed, because setting visible to false seems to disable key handling
    height:0
    width:0
    TextInput{
    id:fake // it's a fake invisible TextInput

        }
    }
    

    ListView {
    id: list
    focus: true

        header:  TextInput { // or whatever with text propery
            id: edit
            text:fake.text // linking with the fake one
        }
    
        Keys.forwardTo : [fake] : // profit)
    

    }

    @



  • Thanks, Its working solution :) with minor additions.

    @
    Item{
    clip:true //this is needed, because setting visible to false seems to disable key handling
    height:0
    width:0
    TextInput{
    id:fake // it's a fake invisible TextInput
    }
    }

    ListView {
    id: list
    focus: true

       header:  TextInput { // or whatever with text propery
            id: edit
            text:fake.text // linking with the fake one
            // Mirror binding to sync both text fields text
            Binding { target: fake; property: "text"; value : edit.text }
            Binding { target: edit; property: "text"; value: fake.text }
       }
    
       Keys.forwardTo : [fake] : // profit)
    

    }@

    But I really confused, why 'ListView.header/footer' is a Component not an Item, as only one header/footer exists for list(unlike delegate). :/

    Thanks again.



  • I think it can cause problems, as it is a bindning loop. but in general you are right, it's important do something about it

    I guess it's because they are dynamically created and have the same behavior as delegates (i.e. it can be destroyed when out of view). But the same thing is with highlight, still there is a highlightItem property for handling highlight instance. i think that could be done for footer and header too int the future releases



  • bq. I think it can cause problems, as it is a bindning loop. but in general you are right, it’s important do something about it

    I guess this Binding will not be a loop as 'textUpdated' signals will be emitted only in case of change in 'text'.

    bq. I guess it’s because they are dynamically created and have the same behavior as delegates (i.e. it can be destroyed when out of view)

    By checking with Qt source i understand that header's life is till the end of ListView. But i am not sure any other resons/advantages being a Component.



  • Here's a simple workaround:

    @ListView {
    id: list
    property variant headerItem
    focus: true

    header:  TextInput {
        id: edit
        Component.onCompleted: list.headerItem = edit
    }
    Keys.forwardTo: headerItem
    

    }@



  • @MartinJ,

    Some how this solution is crashing the application. One point here is in my case 'header' is not directly TextInput, rather its an Item(TextInput is packed inside this) which is the defined in other Qml file, though it should not make a difference just making a point here.

    I guess Keys.forwardTo is getting called before header.onCompleted(), hence the crash :/.

    And one more doubt is 'list.headerItem = edit' - In this case is headerItem is a reference to 'edit' or a copy. If its a copy i guess we may land at the last issue(synchronization of both text's). Its just a doubt, correct me if its a foolish doubt :)

    Your views are welcome



  • [quote author="Amarnath" date="1294389859"]@MartinJ,
    I guess Keys.forwardTo is getting called before header.onCompleted(), hence the crash :/.

    And one more doubt is 'list.headerItem = edit' - In this case is headerItem is a reference to 'edit' or a copy. If its a copy i guess we may land at the last issue(synchronization of both text's). Its just a doubt, correct me if its a foolish doubt :)
    [/quote]

    1. No, that's not a problem - I tried that beforehand and set forwardTo dynamically (and it was possible to do only with PropertyAction connected with onCompleted). sometimes it worked, but crashed when typing

    2. That can't be copying, and should work correctly. So it's probably a bug



  • bq. 1. No, that’s not a problem – I tried that beforehand and set forwardTo dynamically (and it was possible to do only with PropertyAction connected with onCompleted). sometimes it worked, but crashed when typing

    I concluded this by checking console.logs, Keys.forwardTo is shown before header.onCompleted, And in my case no PropertyAction used. And it seemed working fine in my test code where only one List and its header is simple TextInput. but in my actual code its leading to a crash. Strange :)



  • Combination of both solutions would work properly.
    @
    Item{
    id: fake
    clip:true
    height:0 ; width:0
    Keys.forwardTo : [list.headerItem]
    }

    ListView {
    id: list
    property variant headerItem
    focus: true

    header:  AnyItem { // Component/Element
        id: edit
        Component.onCompleted: list.headerItem = edit
    }
    Keys.forwardTo: fake
    

    }@

    Still its not right solution, but works without issues, and can avoid binding loops.

    Thanks for everyone, helping me.


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.