recursively retrieving widgets handlers in wxhaskell
Hi, trying wxHaskell GUI interface, i would like to get a list of all widgets in a frame. My frame is composed of 4 widgets and a panel containing 2 widgets. wlf <- get frame children gives a list of 5 widgets (4 + 1 panel) wlp <- get panel children gives a list of 2 widgets Making wlf ++ wlp gives the whole list of widgets in the frame. But, for a more general use, i want to explore recursively the hierarchy from frame, without having to explicitly know wether the frame contains other containers ... Since the <- syntax to get a list of children, i can't figure out how to write the recursive function to get all children of a frame. I can't write (x <- get widget children) ++ f (rest of list of widgets) , as for usual functions using lists. Thanks for helping. Didier.
On Mon, Apr 05, 2010 at 02:17:40PM +0200, legajid wrote:
trying wxHaskell GUI interface, i would like to get a list of all widgets in a frame.
I can't answer your question as I don't use wxHaskell. That being said, I don't see a reason why you would want to do that. What are you trying to do? Perhaps we could propose you a better solution. Cheers, -- Felipe.
Hi Didier I think I've simplified what you are saying to remove the dependency on wxHaskell. Recursing a widget hierarchy to all get a list of all widgets seems a bit strange, though demo1 does this. Generally I'd expect you would want to recursively process the widget hierarchy collecting some attribute of each widget - demo2 does this. I've put the recursive functions into the IO monad to model wxHaskell where widgets are in some monad. code follows... -- Model widgets as a simple binary tree - labels and interior -- nodes both have names. -- data Tree = Leaf String | Node Tree String Tree deriving (Show) -- simulate the 'get children' on a widget - -- the function is in the IO monad as an analogy -- to wxHaskell being in some monad. -- children :: Tree -> IO [Tree] children (Leaf _) = return [] children (Node l _ r) = return [l,r] -- allTrees returns a list of trees - -- the current tree (t) plus trees of all children (kids_deep) -- Again in the IO monad to simulate wxHaskell being in some -- monad. -- allTrees :: Tree -> IO [Tree] allTrees t = do kids <- children t -- [Tree] kids_deep <- mapM allTrees kids -- [[Tree]] return (t : concat kids_deep) tree1 = Node (Leaf "a") "top" (Node (Leaf "c") "node_b" (Leaf "d")) demo1 = allTrees tree1 -- Simpler idiom just collecting an 'attribute' at each level -- of the tree - here the name. -- allNames :: Tree -> IO [String] allNames t = case t of Leaf s -> return [s] Node l s r -> do { ls <- allNames l ; rs <- allNames r ; return (s:ls ++ rs) } demo2 = allNames tree1
Hi Stephen, Thanks for your answer. I'll look at it carefully to insert it into my project. My question came from my project : manage a book library. A main frame lists all the books in a listCtrl. On this frame, an menu option allows selections on different criterias (author, title, ...). After validating selection, the listCtrl is loaded again, with the books answering the selections. The structure of my program is this one : frame -> intial loading of data (no selections) frame -> menu option -> selection frame then when validated loading data (selections here are updated in the sql query) The loading function is called from two different functions. I want the loading function to display the number of books selected in the status bar. To do this, the function "loading" must get the status field handler. So the selection menu option too, to be able to give it to the "loading". It's a bit boring since "selection" doesnt't need it at all, except to pass it to another function. Adding new functions will certainly add new parameters for their specific needs. My strange idea was : as i have to pass the main frame handler to my functions, the loading function could explore the hierarchy to find the status field, since i give it a specific value for "identity" attribute. So, the only parameter, common to all functions, will be the main frame handler. Why do i pass the main frame handler ? Because my selection function displays a modal dialog, that must refer to the "calling" frame. I see a problem with this approach : no more reference to a field at compilation time (just a handler with a value like 0x.......), so possible error at run time. A second issue is : status field in a statusbar has no identity attribute, like other widgets have (text, buttons, ...). In this specific case, my idea has no solution; i have to change the statusbar into a simple label. But, i want to keep the idea when i write an export function, so the main frame displays a rolling counter as long as the books are written in a csv file. Has anyone already experimented this kind of project? Am i right to do this? Is there another way ? Thanks, Didier 2. n Stephen Tetley a écrit :
Hi Didier
I think I've simplified what you are saying to remove the dependency on wxHaskell. Recursing a widget hierarchy to all get a list of all widgets seems a bit strange, though demo1 does this.
Generally I'd expect you would want to recursively process the widget hierarchy collecting some attribute of each widget - demo2 does this.
I've put the recursive functions into the IO monad to model wxHaskell where widgets are in some monad.
code follows...
-- Model widgets as a simple binary tree - labels and interior -- nodes both have names.
participants (3)
-
Felipe Lessa -
legajid -
Stephen Tetley