How can I move an HTREEITEM to a new parent?


Suppose you have a TreeView control, and you created an item in it, and you want to move the HTREEITEM to a new parent. How do you do that?

You can’t, at least not all in one motion.

You will have to delete the HTREEITEM and then re-create it in its new location.

If you want to move an HTREEITEM within the same parent (say, to reorder it among its siblings), then you can use Tree­View_Sort­Children­CB and pass a custom sort function that rearranges the children into the order you want.

Comments (10)
  1. Seems rather 1950's-ish to not recognize that TreeView_PerformAdoptionProc() should exist. Poor child items don't even get to go to TreeView_Orphanage().

  2. Raymond, you forgot to say that features start with -100 points and aren't implemented by default, and then cite the story of the TreeView control as something the Explorer team made for themselves for a very precise use and then decided to share with the rest of the world :-) .

    Back in they days of the Apple II, you could not move a file to a different directory (let alone another drive) in a single call. You had to create the new file, copy the file contents and the metadata, and then delete the old file. You had the building bricks and was supposed to know how to use them.

  3. Joshua says:

    Back in they days of the Apple II, you could not move a file to a different directory (let alone another drive) in a single call. You had to create the new file, copy the file contents and the metadata, and then delete the old file. You had the building bricks and was supposed to know how to use them.

    That must suck. Atomic rename is one of the few guaranteed atomics on the filesystem on portable code.

  4. CATALOG says:

    I don't remember there being directories on an Apple II… though I was a little kid and only used Apple DOS 3.3 on a //e

  5. @CATALOG: In the old Apple DOS 3.x there wasn't directories. But ProDOS, which used a device-independent filesystem (inherited from Apple III's SOS), did allow them. And had a decent software interface, with a single entry point, well-defined functions, and a coherent parameter passing convention, all of which Apple DOS lacked (but hey, its kernel and command line interpreter used just 10 KB of RAM – those were the times!).

  6. @Joshua: those were the days when if you wanted to port a program, you had to rewrite most of it. With between 30 and 60 KB of available memory (even less if you used graphics modes, which in many machines used the system RAM), most programs were written in assembler, and plugging a runtime library of 10 KB was an overkill.

    Developing for 8 bit machines was a completely different game, not because you didn't have commodities (C compiler, graphics libraries, etc.), but because you couldn't afford them if you didn't want your customers to buy a memory expansion just to run your application.

    And to stay in topic, it still amazes me how much Windows 95 managed to achieve with just 4 MB of RAM.

  7. Smouch says:

    So, when the HTREEITEM has children, who also have children, I'm forced to iterate through all that mess, adding, and deleting any number of items rather than simply re-parenting a single item.  That's why I hate working with most GUI toolkits, unlike perl, they make the trivial things a pain, and the only slightly complicated things downright impossible.

    Just goes to show how a properly designed toolkit makes all the difference.

  8. Tringi says:

    @Smouch: Why do all this? If you know the target Tree-View layout you can easily synthesize comparison function for TreeView_SortChildrenCB.

  9. Tringi says:

    Ah, sorry, read your comment again. Please disregard my previous think-o.

  10. Mike Dimmick says:

    @Antonio 'Grijan': Possibly the fact that Windows 95 had to run in 4MB of RAM, and be sufficiently responsive on a 40MHz 386DX, is why TreeView doesn't support re-parenting an item. If items can be reparented, it introduces another layer of indirection, which is likely to have both time and space costs.

Comments are closed.