1. Listview and Treeview
I've managed to get Treeview working (a bit ahead of schedule!). Check out
I've also sent it to Rob to post. There are a couple of simple demos that
illustrate how things work (basically). I haven't added much fancy wrapping
to it, but you can create, populate, delete and get user selections. Let me
know if there's something you think is missing, and I'll add it!
Matthew W Lewis
2. Re: Listview and Treeview
Matthew Lewis wrote:
> I've managed to get Treeview working (a bit ahead of schedule!).
Very slick, but (as you noted) pretty raw.
It might make sense to treat the listview and treeview as a collection of
controls, rather than as just data in a list. It might make it a lot easier
to change the text or graphic on an item, for example. I'll have to spend a
lot more time with the code - you've done a ton of work!
If would also be nice if the imagelist could be hidden entirely from the
user. The whole point of an imagelist is that the item will eventually be
attached to something. So it might be possible to hide the details with
something like this:
setImage( <id>, SM_CXICON )
Of course, I'd like to support BMP and XMP data as well, so:
setImageToIcon( <id>, SM_CXICON )
might be a better name. The routine could eventually be extended to work
with other controls, like menus, buttons and windows. It would be the job of
the routine to take care of all the gory details:
- if an image list of the proper dimensions doesn't exist, create one
- if the graphic is already loaded, use that pre-loaded one, otherwise:
- convert the graphic data to one the image list will accept
- add the graphic to the image list
- cache the graphic name, so it can be shared
- free memory
- attach the graphic to the requested control
It might even make sense to eventually deprecate setIcon and setBitmap and
replace them with setImageToIcon and setImageToBitmap.
-- David Cuny
3. Re: Listview and Treeview
David Cuny wrote:
> It might make sense to treat the listview and treeview as a collection of
> controls, rather than as just data in a list. It might make it a lot
easier
> to change the text or graphic on an item, for example. I'll have to spend
a
> lot more time with the code - you've done a ton of work!
I've thought a bit about that, but did't want to implement anything on my
own, since there will be many things to change. And it's not clear to me
what the best way will be. Especially with the listview, since it's more of
a glorified listbox, and might make more sense to treat it as a collection
of data that might be erased and modified a lot. We'll see. I think that
the best indicator of where to go is to see how people use them, and follow
any suggestions that arise.
Of course, let me know if you have any questions about the code. I tried to
keep it pretty clean, but there aren't many (any?) comments. Once I 'broke
the code' on the listview, the treeview was pretty easy. It probably took
me as long to get all the constants in as anything else (for the treeview).
And actually, Wolfgang asked me about the time it takes using equations to
define the constants. I told him I was just too lazy to convert them (since
that's how they were in my cmctrl32.h file). So maybe that's something else
to do to speed up load time a little.
BTW, I never really understood how your structures worked in win32lib, but
now that I've had to use them, they're pretty handy.
> If would also be nice if the imagelist could be hidden entirely from the
> user.
Absolutely. I just wasn't sure how to do it without rewriting tons of stuff
(as you note below:) and possibly breaking code.
> The whole point of an imagelist is that the item will eventually be
> attached to something. So it might be possible to hide the details with
> something like this:
<SNIP>
> The routine could eventually be extended to work
> with other controls, like menus, buttons and windows. It would be the job
of
> the routine to take care of all the gory details:
<SNIP>
> It might even make sense to eventually deprecate setIcon and
> setBitmap and
> replace them with setImageToIcon and setImageToBitmap.
Let me know if you'd like some help with anything. I think my next project
will be figuring out MDI apps.
Matt Lewis
4. Re: Listview and Treeview
Matthew Lewis wrote:
> And it's not clear to me what the best way will be.
Any idea how it's done in VB? I'm going to look in my Qt and GTK/Gnome
documentation when I get it unpacked. I think a good rule of thumb is to
make simple enough that it makes 80% of the users happy.
> Of course, let me know if you have any questions about the code.
I doubt I'll have a chance to look at it in any depth for the next couple
days. I'm still in the process of unpacking, and the computer isn't hooked
up yet. But I'll be sure to holler!
> BTW, I never really understood how your structures worked
> in win32lib, but now that I've had to use them, they're
> pretty handy.
I like the way you define routines to populate the structures, and return
them. Pretty slick.
> I think my next project will be figuring out MDI apps.
I think placing documents in tab controls (like Excel) is a better scheme.
Yeah, Write is a good example of that interface applied to a word processor.
One thing that really annoys me about Word is that there's no trivial way
(that I know of) to toggle between documents; you have to select Window from
the menu, and then the document from the menu list. Very odd.
-- David Cuny
5. Re: Listview and Treeview
David,
FYI, in Word 2000 (and 97), <Ctrl+F6> and <Ctrl+Shift+F6> to switch between
documents.
----- Original Message -----
From: Cuny, David at DSS <David.Cuny at DSS.CA.GOV>
> > I think my next project will be figuring out MDI apps.
>
> I think placing documents in tab controls (like Excel) is a better scheme.
> Yeah, Write is a good example of that interface applied to a word
processor.
> One thing that really annoys me about Word is that there's no trivial way
> (that I know of) to toggle between documents; you have to select Window
from
> the menu, and then the document from the menu list. Very odd.
>
> -- David Cuny
>
6. Re: Listview and Treeview
David Cuny wrote:
> Any idea how it's done in VB? I'm going to look in my Qt and GTK/Gnome
> documentation when I get it unpacked. I think a good rule of
> thumb is to
> make simple enough that it makes 80% of the users happy.
I'll look into the VB angle. All I have is a working version here.
> I like the way you define routines to populate the
> structures, and return
> them. Pretty slick.
Thanks. Just another product of being lazy...:)
> I think placing documents in tab controls (like Excel) is a
> better scheme. Yeah, Write is a good example of that interface applied to
a
> word processor.
In some cases, I agree with you. But if you want more than one
window/document to be visible, tab controls won't work.
> One thing that really annoys me about Word is that there's no
> trivial way (that I know of) to toggle between documents; you have to
> select Window from the menu, and then the document from the menu list.
Very odd.
Try CTRL+F6. From the Win32 Programmer's Reference:
"Accelerator keys on the System menu for an MDI child window are different
from those for a non-MDI child window. In an MDI child window, the ALT+ -
(minus) key combination opens the System menu, the CTRL+F4 key combination
closes the active child window, and the CTRL+F6 key combination activates
the next child window."
I didn't know how to do it either, until I read that this morning...
7. Re: Listview and Treeview
It seems to me that when the compiler is available that win32 will
be a dead issue because when "C" code is generated it can be linked
to anything that you want do in windows. There will be no need for
for exw or a win32 library.
8. Re: Listview and Treeview
Bernie wrote:
>
> It seems to me that when the compiler is available that win32 will
> be a dead issue because when "C" code is generated it can be linked
> to anything that you want do in windows. There will be no need for
> for exw or a win32 library.
Not true. You can link to anything you want to in windows right now, so
that's no different. That doesn't make it easy to program. Besides, some
people might not want to learn C. Having a nice, high level wrapper for the
Win32 API will still be important to the majority of programmers.
Personally, I've found that Win32Lib has made it easier to program
(interfaces) in windows than in DOS. I'm sure there are some who'll
disagree with me, though. :)
Not that I'm not looking forward to the compiler!
Matt Lewis
9. Re: Listview and Treeview
"Cuny, David@DSS" wrote:
> One thing that really annoys me about Word is that there's no trivial way
> (that I know of) to toggle between documents; you have to select Window from
> the menu, and then the document from the menu list. Very odd.
>
> -- David Cuny
Ctrl-Tab. Obscure, but works in nearly all properly programmed Windows software.
10. Re: Listview and Treeview
- Posted by "C. K. Lester" <cklester at HOTPOP.COM>
Jun 26, 2000
-
Last edited Jun 27, 2000
Ctrl+TAB just inserts a tab in a word document. Maybe you meant Alt+TAB to
switch between applications...
> Ctrl-Tab. Obscure, but works in nearly all properly programmed
> Windows software.
>
>
13. Re: Listview and Treeview
Bernie wrote:
> It seems to me that when the compiler is
> available that win32 will be a dead issue
> because when "C" code is generated it
> can be linked to anything that you want
> do in windows. There will be no need for
> for exw or a win32 library.
Erm... no. Win32Lib provides glue between Euphoria and Windows by doing
exactly what you describe: linking to Windows. In addition, it provides an
nice bridge between Euphoria data types and C data types. Even if you went
to MFC, you would still have to write glue code to link Euphoria to Windows.
In addition, Win32Lib provides (in my not so humble opinion) a nice layer
between the programmer and the raw Win32 calls.
-- David Cuny
14. Re: Listview and Treeview
Couldn't agree with you more. And some (at least one) of us are grateful for
your
efforts because we don't want to program in C - that's why we're using Euphoria.
David Cuny wrote:
[other stuff deleted by Ben]
> .....In addition, Win32Lib provides (in my not so humble opinion) a nice layer
>
> between the programmer and the raw Win32 calls.
>
> -- David Cuny
15. Re: Listview and Treeview
Ben Fosberg wrote:
> Couldn't agree with you more. And some (at least one)
> of us are grateful for your efforts because we don't want
> to program in C - that's why we're using Euphoria.
And since this is turning into a virtual lovefest, thanks again to the
coders and debuggers who contributed to the project. I've gotten a *lot* of
help on various parts of the library, and am grateful for the help.
-- David Cuny
