Erik, have you checked-out the CHM yet ? It was your prodding that kept me going on that. Although not 100% done yet. It has all the "new stuff" and will be completed before the final. And going forward, religiously maintained. The CHM can be considered a beta as well. Its the first public release, so there are probably bugs and inconsistencies in there ... would love to get feedback on the CHM (in any regards) as much as the DLL itself.
Thanks again for encouraging me on that CHM ...
-Shawn
[ 04. July 2003, 23:13: Message edited by: Shawn ]
Registered: 2000-11-27
Posts: 1222
Loc: Gothenburg, Sweden
shawn, I think the CHM is wonderful Well thought through. Perhaps some more examples would be nice though One thing that I really miss though is the Content/Index/Search tabs
yeah, definitely need more examples, would like to have a large example for each object. if anyone wants to contribute an object example please feel free to send it my way ... for example, here is a ProgressBar example (that hasn't made it into the CHM yet) ... basically what they do is demonstrate all the features of each object ...
if that is an progressbar example (like you said it is) it's 19001% overkill. simple example of the features functionality is enough.
here you have a whole script (totally unrelated) and a function library included.
basically progressbar can exampled with some lines. you don't have to create database accessing script that does some fancy html stuff on the bacground and shaves your bosses hair just to show what the object/event/property does.
Registered: 2000-11-27
Posts: 1222
Loc: Gothenburg, Sweden
hehe.. yeah, perhaps it's a good idea to stay away from the bosses hair
Anyhow, like we discusses at the KiXforms forum too, just small explainatory ones, dealing with the explicit function Your point is good though shawn, it's also nice to see "real examples" of it's usage too.
Perhaps each (or as many as possible) object could have an "Examples" page in the CHM, where the first example is a very basic one. Then if there's more examples available, they could advance for each example or something
ja, small snippets of examples are ok, but its a real pain-in-the-butt when one actually has to write an entire script just to see the snippet in action (especially with graphics asre involved). Its just like the .NET examples on MSDN, some are snippets and some are entire programs - the ready-to-run ones are the best. In fact, that ProgressBar example is a straight port of the .NET ProgressBar example
ja, good idea. Since I want (to try) to be a bit more carefull going forward in terms of dotnet compatibilty, lets compare your suggestion (which I like) with the quasi-dotnet version ... which you may or may not like:
Every object that can generate a keyboard event (like OnKeyDown, OnKeyPress, OnKeyUp) has a property called "KeyEventArgs" that returns a KeyEventArgs object. This object has the following properties:
For example, the "Alt" property returns a value indicating whether the ALT key was pressed. The "Control" property returns a value indicating whether the CTRL key was pressed. The KeyCode, KeyData and KeyValue properties return info about what key was pressed.
Looking at some MSDN examples, kixscript would look like:
$e = $Form.KeyEventArgs
If $e.KeyCode = ASC("A") And ($e.Alt Or $e.Control OR $e.Shift) ; .. EndIf
Dotnet developers (and dotnet function prototypes) always seem to want to "cast" xxxEventArgs to a variable called "e". But long story short, this is the dotnet way of things, but the way you suggest is more straight-forward I think, but the again, when I deviate from things it always tends to bite me latter Thoughts Erik ?
ja, good idea. Since I want (to try) to be a bit more carefull going forward in terms of dotnet compatibilty, lets compare your suggestion (which I like) with the quasi-dotnet version ... which you may or may not like:
Every object that can generate a keyboard event (like OnKeyDown, OnKeyPress, OnKeyUp) has a property called "KeyEventArgs" that returns a KeyEventArgs object. This object has the following properties:
For example, the "Alt" property returns a value indicating whether the ALT key was pressed. The "Control" property returns a value indicating whether the CTRL key was pressed. The KeyCode, KeyData and KeyValue properties return info about what key was pressed.
Looking at some MSDN examples, kixscript would look like:
$e = $Form.KeyEventArgs
If $e.KeyCode = ASC("A") And ($e.Alt Or $e.Control OR $e.Shift) ; .. EndIf
Dotnet developers (and dotnet function prototypes) always seem to want to "cast" xxxEventArgs to a variable called "e". But long story short, this is the dotnet way of things, but the way you suggest is more straight-forward I think, but the again, when I deviate from things it always tends to bite me latter Thoughts Erik ?
I appreciate your effords to make KiXforms .net compatible.
This gives others (me ) a chance to see/understand some of the 'weird' ways of programming methods we have to use today.
By following a lot of threads on this board i had learned a lot about AD before implemting it.
For this reason, I believe that you should stay as close to .net syntax as possible.
This way it is easyer to convert VB-code to KiX-code and reverse, also esyer to understand both kinds of code-ways.
I think you should stay on the .net road and disregard my 'oldfasion' way of keeping the code small. This way we can stil benefit of the willingness of the members on KiXtart.org to share knowledge and learn something of M$ world at the same time.