Yes Jared, tasks are vary depending on usage.
My Cuckoo clock program was an expansion from the original Hourly
Program that had only slight adjustments. But I had said, I used that as a
learning tool, so all additions are actually to learn the WE Object model.
Converting all options to menu check items and sub programs to other
dialogs, to perform a needed action.
Then I expanded it using a treeview below the menu for new features;
which I posted in my example, just did not go into detail inside the call
proc for the dialog.
Jared you are essentially using the App Development Reference inside the
help menu as a quick reference which is fine if wanting to use it that way.
All I was asking is to just improve it a little, not write an encyclopedia.
Who knows, when thinking back at my original problem/hitch, it could
have been as simple as leaving out the key word SET. Don't know, can't
remember, for I was trying ideas, sometimes guessing on what the App Manual
was saying, and moved on when it failed.
I ended up with the keyup event and it resolved all issues and only
needed a simple watch of a single key event and not make a hotkey that would
be universal through the entire dialog. Which I discovered was a problem
when changing the spacebar key. Now I could have used a key not used
elsewhere, but, as I stated before, I wanted commonly used, standard key
functions, to make it work. The spacebar is used to select and also to
check, and also to click on something. Perfect for what I was attempting,
and just needed to figure out how to do it without making the hotkey which
is what I did first and that created al the issues I just mentioned.
Now having said that, maybe I could have done a filter test for that
hotkey, don't know if it would have worked, but don't know all the
techniques that could have been used since the App Development Object Tree
View is essentially a Quick Reference list.
Which brings us back to my original simple improvement suggestion.
Granted it is less confusing than going to the Microsoft web site that says
go to this link, then this link then this link, which you can easily get
lost in; especially when they give names of flags then another page gives
there values, not all on the same page...
Having working examples where the list of properties and methods would
be a nice addition. Having event numbers with the event names in the same
location. Like attempting to find all the treeview event names, but
discovering they are not in the treeview control section...the only place
treeview is mentioned.
Take care, Bruce
Sent: Saturday, August 13, 2011 5:39 PM
Subject: Re: Tree view
I see. To each their own, of course. I prefer more slimmed down API
references segregated from detailed teaching aids and haven't felt it
difficult to find what I need in the WE docs. But I don't get to choose
what's in the WE docs, so what I think doesn't really matter.
On 8/13/2011 11:06 AM, BT wrote:
> Hi Jared,
>
> That is the usual explanation and nothing gets done. There are some
> great examples in some of the Object Model tree view, but as you point
> out,
> a person jumps around and around. So, excusing it only prevents one
> concise
> simple reference manual.
> As I said a reference manual should show more of what an engineer has
> written with a proven example; like the W3 Schools attempts to do, also
> using web live examples when possible. I am not saying live examples, but
> an
> example can make things a lot easier; immediate mode does this feature
> when
> you run the example.
>
> Python also does this and it is an open source, free stuff and in
> almost
> all cases you have the huge manual to go through.
>
> When Aaron asked I had mentioned to just give an example in the
> location
> where it says it is a so and so object. I even have to look in some other
> text to even find the Treeview and Listview event names, it is not in the
> Help Menu App Doc; searching for something you must no how it is spelled
> first and guessing maybe you get lucky.
>
> I assumed the Key object is a stand alone like the keyboard object
> is,
> according to the logic of the tree view list and when creating an object
> it
> said none was created...
>
> Inside the Keyboard object it uses the Keys, plural form, and search
> around for another place where key was mentioned and decided to quit
> looking
> at that point because there was only the main list one which I already
> attempted to use.
>
> But, as I said, as long as people say it is not for the novice, yet
> people keep on asking, and keep getting these responses, nothing gets
> done.
>
> I am not knocking Chip for he is going through one example at a time
> and
> there is documentation of what he is doing, all I am asking for is the
> final
> project, "All In One Location!"
>
> Sincerely
> Bruce
>
>
> Sent: Friday, August 12, 2011 11:45 PM
> Subject: Re: Tree view
>
>
> On 8/12/2011 2:11 PM, BT wrote:
> "Granted experienced programmers don't need it, but first time users do."
> API references aren't really for first time programmers though, at least
> not without something else to guide their exploration. That's where the
> Wiki, Chips' audio classes, etc. prove their worth.
>
