|
|
|||||||
The latest Kixforms Beta 3 Special Build 2 is now available ... it addresses the following issues ... 1) Incorrect default StartPosition of Form. 2) Incorrect painting of TabControl background Hopefully these are the only issues with the Beta, I encourage you to report anything else suspicious .. thanks -Shawn |
||||||||
|
|
|||||||
Thank you Shawn, I use KiXforms with great plesure. I'm 'silently' implementing it in my AD-domain. So thanks to KiXforms AND WKiX32 it is possible to totally avoid the 'DOS' console Even if you 'hide' your script via AD-policies it is only the 'console' that is hidden. The dispaly of Forms from KiXforms is stil displayed -Erik |
||||||||
|
|
|||||||
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 ] |
||||||||
|
|
|||||||
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 |
||||||||
|
|
|||||||
actually, you are right. those are the only reasons why to set up a chm. a really simple doc or even web-page can better offer the basic form of chm. but the strength of chm is in the search and index and local cache and... |
||||||||
|
|
|||||||
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. |
||||||||
|
|
|||||||
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 -Shawn |
||||||||
|
|
|||||||
Thanks again Shawn, The .chm file looks very nice. I just observed the KeyCode property while making a quick browse of the .chm A suggestion: Could you make it possible to check if more than one of the flag-keys: Alt,Shift,Control are down at the same time By giving them the values 1,2, and 4 And then make this return true only if all 3 keys are down: $state = $Object.KeyState(7) Or return true if Alt and shift are down: $state = $Object.KeyState(3) -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: KeyEventArgs.Alt KeyEventArgs.Shift KeyEventArgs.Control KeyEventArgs.KeyCode KeyEventArgs.KeyData KeyEventArgs.KeyValue 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 ? -Shawn |
||||||||
|
|
|||||||
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: KeyEventArgs.Alt KeyEventArgs.Shift KeyEventArgs.Control KeyEventArgs.KeyCode KeyEventArgs.KeyData KeyEventArgs.KeyValue 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 ? -Shawn |
||||||||
|
|
|||||||
Shawn, 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. -Erik |