PHP-GTK2 Cookbook Forum
Welcome, Guest
Please Login or Register.    Lost Password?
Re:Access Treeview cell renderers. (1 viewing) (1) Guest
Go to bottom Post Reply Favoured: 0
TOPIC: Re:Access Treeview cell renderers.


#180
reid (User)
Fresh Boarder
Posts: 4
graphgraph
User Offline Click here to see the profile of this user
Access Treeview cell renderers. 5 Years, 1 Month ago Karma: 0  
Hi there, I need to change the cell attributes of a treecell after all the data has been loaded. I'm making an ftp upload queue that enables the user to right click a row and remove it from the queue. The problem is, when the queue is initially built from a text file of filepaths, a callback function renderers all column cells 'red' on a row if the individual filepath is invalid, but when the user removes a row from the treeview, the row below it is then rendered in red even if it is a legit file and should be rendered normally. I've tried clearing the whole list and re-inserting the data, but the rows are still rendered red. I could remove all the columns too and call the functions to rebuild the columns first (if i knew how to remove all the columns), and then re-add the columns, and then the data, which would reformat the whole list properly. I would rather just check all the items on the list and send a message to the cell renderer if it needs changing. It is also possible that a file that was invalid on program startup, would become valid after the user has moved files around while the program is running. In which case I need the list updated at arbritrary times and the cells would be rendered differently based on the changed status. I have attached a few images to try and help explain my problem (im not even sure i understand it :)



The first two items on the list are invalid and therefore the whole column is rendered in red font.

The user removes an item from the queue.

Now the second item is dsiplayed red even though it is legitimate and should be in black (like it was).

Thank you in advance for your time and effort :)
Paul.
 
  The administrator has disabled public write access.

#182
kksou (Admin)
Admin
Posts: 1680
graph
User Online Now Click here to see the profile of this user
Re:Access Treeview cell renderers. 5 Years ago Karma: 27  
Hi Paul,

You didn't attach any of your code. So I do not know where's the error.

But based on what you've described and the pictures you've attached, I've created a sample code for you:
Sample Code 485: How to highlight specific rows or cells in treeview

Compare the code with yours. I think you should be able to find out where's the error.

Regards,
/kksou
 
  The administrator has disabled public write access.

#198
reid (User)
Fresh Boarder
Posts: 4
graphgraph
User Offline Click here to see the profile of this user
Re:Access Treeview cell renderers. 5 Years ago Karma: 0  
kksou.
Thank you for all the time and effort you put into answering this post!
I have followed your advice and changed my code to suit your sample above. Initially I didn't want to re-build the list every time a change was made because this introduces unnecessary processing.
I now clear and rebuild the list everytime a change is made and format the rebuilt list using a cell_data_func callback. This has led me to another problem - everytime the user mouses over the list the callback is called. How can I stop this from happening?
Thank you again,
Paul.
 
  The administrator has disabled public write access.
#199
kksou (Admin)
Admin
Posts: 1680
graph
User Online Now Click here to see the profile of this user
Re:Access Treeview cell renderers. 5 Years ago Karma: 27  
reid wrote:
Initially I didn't want to re-build the list every time a change was made because this introduces unnecessary processing.
I now clear and rebuild the list everytime a change is made and format the rebuilt list using a cell_data_func callback.


Hi Paul,

It's fine to rebuild the list. But when the user right click on a row to remove it from the queue, you can just remove that row from the underlying data model. In this way, you do not need to rebuild the entire list.


This has led me to another problem - everytime the user mouses over the list the callback is called. How can I stop this from happening?

I know the fact that the cell_data_func is called so frequently (e.g. everytime there's any update in the underlying model or any movement in the treeview) makes us feel that it will be very inefficient and will cause some flashing of the screen.

However, having worked with the treeview for so long, I was always amazed at this cell_data_func. It seems to have its own internal optimization to process the treeview update efficiently.

For example, take a look at this example:

Sample Code 490: How to have a start stop button in GtkTreeView - Part 1 - using liststore

You can see independent hundredth-second timer running concurrently across every row as shown below:



So, don't worry too much about the cell_data_func being called too many times or feel that it's being inefficient. Most of the time, if there's any slowness in your application, it's usually not due to the cell_data_func.

(By the way, if you're echoing any debugging information to the command window in this function, try to turn them off in your "live" application. I find that any echoing of information to the command window from within the cell_data_func will significantly slow down the efficiency of this function.)

Regards,
/kksou
 
 
Last Edit: 2008/05/07 15:33 By kksou.
  The administrator has disabled public write access.
#200
reid (User)
Fresh Boarder
Posts: 4
graphgraph
User Offline Click here to see the profile of this user
Re:Access Treeview cell renderers. 5 Years ago Karma: 0  
Hey /kksou, thanks for your ongoing assistance, hopefully after a few weeks I'll be able to answer a few questions for you, give you a bit of time off :D
Anyway, I can see that the cell_data_func call in itself is not a performance hit. Whilst writing my reply and pasting my code to this post, I noticed that I had a call to another class that returned the status of each individual entry and it was this accessing of the outside class that was making the application jerky and unresponsive.
Back to work! Speak to you soon no doubt :)
Regards, Paul.
 
  The administrator has disabled public write access.



Go to top Post Reply
Powered by FireBoardget the latest posts directly to your desktop

Blog - Forum - Privacy Policy - Contact Us
Links - Classes - Social Business - BPM - Web - General
Copyright © 2006-2013. kksou.com. All Rights Reserved