|
|
|||||||
On behalf of Shawn, I am pleased to announce the release of KiXforms 2.1.2 (Build 36) which is available for download from the KiXforms web site: KiXforms Download Page The release notes are as follows: ListView Object Added support for deleting columns from the ListView object. The syntax is as follows: $ListView.Columns(#).Remove $ListView.Columns.Remove(#) SpinButton Object Fixed the SpinButton long duration click behavior. The control will no longer stall when holding down the arrow buttons. Also corrected automatic SpinButton acceleration. The new behavior is that as the arrows buttons are depressed for various durations, the increment (or decrement) will accelerate by more than one. Refer to following table for acceleration levels: 0-2 Seconds = Value +/-1 2-5 Seconds = Value +/-5 5+ Seconds = Value +/-20 Icon Support Added support for extracting icons from EXEs. The syntax is to provide the full path of an executable followed by the index number of the icon to extract; for example: $Button.Icon = "c:\folder\program.exe;n" This release of KiXforms will return the 32x32 (large) version of the icon. It cannot return the 16x16 (small) version of the icon at this time. Bug Fix Fixed the changing of BorderStyle=0 for all controls. Prior behavior did not account for expansion or contraction of the client area by the addition or removal of a border. The effect was mostly evident for the Image control where bitmap a was stretched incorrectly. The new behavior accounts for this. As always, please feel free to add any comment, questions or feedback to this thread. Rod. |
||||||||
|
|
|||||||
Just wanted to add that when I implemented the EXE icon extraction code, because of the nature of the way the icon/path is specified (its a property, not a method call), I had to choose between returning a small or large icon - and I decided to go with the large icon (32x32). If the EXE has only small (16x16) icons, they will still return as 32x32 but then the developer can decide to shrink it back down to 16x16 using the Width/Height properties. I thought that this might make a better alternative then to have the 16x16 expanded to 32x32. In the future, I will be implementing the LoadIcon() method call for all objects, and it will go something like this: $Button.Icon = $Button.LoadIcon("path",index,size) And this will bring the extraction of icons from DLLs,EXEs and ICOs under one roof, and allow the developer to specify the icons size and other things. As well, might make it so that if the developer specified -1 for the index, the method would return the total number of icons available in the resource. Not sure if this would be terribly usefull or not, but the method version extraction would give us this flexibility. -Shawn [ 03. November 2002, 23:06: Message edited by: Shawn ] |
||||||||
|
|
|||||||
Great ! Two things to mention though RichTextBox Control : won't add the bookmark hyperlinks refering to positions in text created with word ... seems to react just as if you open that with Wordpad, any chance to get this working ? Radio Buttons on Child form : The freeze Issue is definetly solved But it still seems to fire an event if there is no activity on the buttons - You know the effect : Having 3 options on first run it is all ok, on second Option 3 gets selected , 3rd will select option 2 and then toggles between 3 and 2 J. |
||||||||
|
|
|||||||
j, as discussed will look into this issue and the zorder thingy asap. Just as an fyi, and with the caveat that its only just started and subject to change, the beginnings of the RichTextBox object are included in this release (build 36) ... for anyone thats interested and has an RTF file they would to embed within a form, heres a sample script: code:From my experience, and in seeing what Jochen is up to (his idea), the RichTextBox control has one very cool use. If you want to build an online HELP system for your script, simply write it up using wordpad and RTF, then create a simple dialog form with an embedded RichTextBox and a close button, and display that. I must admit that it looks very professional.Break On |
||||||||
|
|
|||||||
Jan, What size icon will you be working with - 16x16 or 32x32 ? Was just "surveying" some standard windows applications, and was thinking that in the short-term, maybe the 16x16 size might actually be the better default to return from the exe extraction. It seems that small icons are used for the following: 1) Menu Icons 2) Toolbar Menus (Rebars) 3) Some button captions 4) ListView small icon report view And the larger icons are used for: 1) Button captions 2) ListView large icon report view All-in-all, both formats are needed but maybe the small icon would have more short-term usefullness, not sure, what are your thoughts. |
||||||||
|
|
|||||||
Any chance of getting the FileCopy dialog included? |
||||||||
|
|
|||||||
Chris - yeah - im all for that. |
||||||||
|
|
|||||||
Could you add a .style option to the scroll bar to change between a blocky look (as is now), and a smooth look, where the bar is solid. Thanks, W |
||||||||
|
|
|||||||
If you do, I promise to switch my KiXGUI logon script over to KiXforms. |
||||||||
|
|
|||||||
Wizard, do you mean the ProgressBar or the ScrollBar ? If ProgressBar, set the Style property to 1 for smooth peanut butter. |
||||||||
|
|
|||||||
Bugger. I meant Progress Bar. Thanks |
||||||||
|
|
|||||||
Shawn, I now use the 32x32 icons to use in a login script (status reporting, will sent you an screenshot one of these days), but initially i wanted to use icons to place in front of the username, domain, workstation etc to show a glossy loginscript... In the last case i would like 16x16 icons |
||||||||
|
|
|||||||
I have just noticed something, the .Visible property does not work on ProgressBars or Labels, unless I am typing it wrong.! code:Where $fraStatus is a frame and $lblFuncStatus is a label within the frame. I have tried code:but still no luck. |
||||||||
|
|
|||||||
I think that object on a form are visible when the form is visible, unless you drop then object and/or recreate them. Drop the object like: code:lblFuncStatus=0 |
||||||||
|
|
|||||||
But then, wouldn't that degate the need for the .visible I am modifying the fantastic demo login script written by Chris S The demo has a seperate window popup with a second progress bar for step completion within a function. I have changed that by having two progress bars on the one form, but I wanted to hide the second progress bar when not in use. Its not a major thing to get working, I just thought I found an issue with the .visible tag. Thanks W |
||||||||
|
|
|||||||
Wizard, strange thing as I am surely able to hide both labels and progressbars (verified with KiX-O-Matic and the current script I worky on) .Visible = 0 that is |
||||||||
|
|
|||||||
wiz, was able to to verify expected behavior of hiding/showing ProgressBar with this code. In terms of negating the usefullness of .visible, the following statements have two very different meanings: $ProgressBar.Visible = 0/1 Hides or shows the progressbar. The object still persists and is 100% functional and usable, can even set properties and change the Value while its hidden. This statement: $ProgressBar = 0 Disposes the object completely so it doesn't exist anymore. Calling properties and methods on a disposed handle may or may not generate Kixtart runtime errors. Heres the code: code:-ShawnBreak On [ 06. November 2002, 13:59: Message edited by: Shawn ] |
||||||||
|
|
|||||||
I found the problem.! I am defining a form. Then a frame within the form Then a lable within the frame. This is does not like.! Using... code:the .visible does not work. But if I define the $prgStatus = $fraStatus.ProgressBar as an object of the form rather than the frame $prgStatus = $frmMain.ProgressBar then the .visible bit works.$frmMain = CreateObject("Kixtart.Form") Is that a bug, or just quirky.?? W |
||||||||
|
|
|||||||
Good one - it does work (the progressbar goes invisible) but the frame doesn't refresh properly, try your code again, then "wipe" a window (ie, the DOS box) over the frame - should see that the progressbar is hidden. hmmm ... must fix that. Or might try this code: code:Break On |
||||||||
|
|
|||||||
Hmmm ... speaking of frames : I wasn't able to place a Picturebox being visible inside a frame, may this be the same Issue ?` J. |
||||||||
|
|
|||||||
One should be able to place a PictureBox in a frame, I just ran a modified version of the above script with these amendments: code:Seemed to work ok ... We definitely need a new and improved FRAME for Kixforms ... think we already discussed this refreshing issue in the past. j, might want to verify your issue by "wiping" other windows over your form. Or by minimizing then maximizing the form.$prgStatus = $fraStatus.PictureBox |
||||||||
|
|
|||||||
hmm ... think we got back on the god olde child form track : No way to wrap a frame around my cards selection thing {edit} Sorry , even fails on parent form If i size the frame smaller in height as the shown cards they will appear below but the frame seems to be drawn as a 'solid' element Will mail you the test script (place it in the hearts folder) {/edit [ 06. November 2002, 15:44: Message edited by: jpols ] |
||||||||
|
|
|||||||
Ah ... and congrats on the 4th Millenium post J. |
||||||||
|
|
|||||||
Shawn, here's an idea, why not make the frame object a non-containing (for want of a better word). ie, You can't add items within a frame object only a form object. I know this is against VB, but it might save you alot of work. W |
||||||||
|
|
|||||||
Well, I will give some background in terms of what the problem is. The problem is that I'm trying to support two different ways of showing child controls in a frame. 1) Some folks create controls that are children of the form, then use a frame to visually group the controls. In this case, the frame must be totally transparent so that the child controls can be seen. If the frame is moved, the child controls do not move with. Plus, RadioButtons that are grouped this way are not mutually exclusive by default. 2) Other folks create controls that are children for the frame. In this scenario, the frame doesn't have to be transparent and if the frame is moved, the child controls move with it. RadioButons grouped in this fashion are mutually exclusive by default. The second option is actually the one I had in mind for proper usage of a frame. If you actually look at VB .FRM statements, child controls "appear" to be children of the frame, and not the form. They seem to be created in a nested fashion. So what I did, when I created Kixforms v2, was to make the frame non-transparent. The refreshing issue as we see it now, was not a problem. Plus, one could actually set the BackColor of a frame if one wanted. But - when I went back over some legacy scripts that I had - found some scripts that did things "the other way" and the frame hid all the controls underneath. So caught between a rock and a hard-place right now. Its important to realize that BOTH methods are correct. For example in regular C++ dialogs, the child controls placed in a frame are not children of the frame, they are owned by the dialogbox itself. The frame is just used for visual grouping. The difference is that one doesn't noramally see controls appear and vanish on the fly - plus, C++ dialogs are statically declared and built before they are shown - with Kixforms and Kixtart scripting - the controls are built on the fly - thus we sometimes see them move and flash in certain circumstances. Thats why we usually defer showing the form until just before the DoEvents loop - to keep things hidden until the form is fully rendered. To change the FRAME behavior this late in the game might be a mistake. The other option you might want to explore is to use the PictureBox object - which can also act as a container. To be honest - the PictureBox object is a FORM ... diff being that its owned by the parent form - its really a borderless sub-form. It has a persistent bitmap background just like a regular form, and can host child controls. The next best option is to explore a new type of container control - which I've already started to do. dotnet has an object called a "PANE" with behave very much like a frame (its the dotnet version of a frame - its also called a GROUPBOX in some other circles) - the discussion will really center around whether this new control wil REQUIRE that the contained controls be created as children of the pane. My take is that this should be a requirement. [ 06. November 2002, 16:43: Message edited by: Shawn ] |
||||||||
|
|
|||||||
I am a VB programmer mainly and I do use the second method - but only because it is easier to move a group of object around the screen quickly with drag'n'drop. I will fully support any choice you make.! I think I'll just keep my progress bar visible.! W |
||||||||
|
|
|||||||
yeah, i always use the frame child thingy to - mostly because I always end up moving and adjusting and tweaking the form afterwards, its a whole lot easier to just re-position the frame, then have to re-calculate all the child controls as well. here's the picturebox version of the script. it would simulate (pretty closely) how a dotnet pane object would behave (except for the etched border and caption, which isn't there) - but you could draw your own if you wanted ... HEY Wiz - How about getting a little splash of color in those forms of yours, eh ? I always get much high praise from Jochen for my splendid use of color - right J ? code:Break On |
||||||||
|
|
|||||||
Plus don't forget, there is a whole suite of powerfull graphic functions built into Kixforms for desiging custom controls, fe. don't like how the frame object looks - just design your own using the generic PictureBox control with a custom paint job : code:Break On [ 06. November 2002, 18:15: Message edited by: Shawn ] |
||||||||
|
|
|||||||
And - if I may be so bold - I think the script that opitimizes the power of a custom paint job is in the yet unpublished (but infamous) RatProgressBar created by one NTDOC (aka Ron). Hopefully, if he reads this far, he will correct this oversight on his part. |
||||||||
|
|
|||||||
I'll look for it at home tonight and post it. :-) |
||||||||
|
|
|||||||
Here is the RatProgressBar Shawn was speaking of. code:Break On |
||||||||
|
|
|||||||
Does that come with a copyright release? |
||||||||
|
|
|||||||
just a fyi Shawn, I managed to build that card select thing into a frame by making the frame a child of PictureBox, wonder though why I had to make the rectangle drawing child of the form, but hey, it works now J. |
||||||||
|
|
|||||||
Another thing for the update list : Experienced that vertical alignment for labels is always Top, this is a bit disturbing when using labels as fake status bars ... How about making default VAlign to center or even add a .VerticalAlignment property ? J. |
||||||||
|
|
|||||||
J, could you not just change the .TOP value of the label to keep it in line, or am I missing something ? W |
||||||||
|
|
|||||||
That would fit if the label itself has no border, true ! Just take a look at Shawns Kiwi script bottom of the form Jochen |
||||||||
|
|
|||||||
yeap, it was me missing something.! sorry. I see your point now. Yes, can we have a .valign tag please. W |
||||||||
|
|
|||||||
j, ok im with you now ... well spotted - I will add the following new property: $Object.TextAlign = Number Gets or sets the alignment of text in the label. Number One of the following values: 0 - TopLeft (Default) 1 - TopCenter 2 - TopRight 3 - MiddleLeft 4 - MiddleCenter 5 - MiddleRight 6 - BottomLeft 7 - BottomCenter 8 - BottomRight [ps] This is an example from some of the new documentation Im putting together ... the work is progressing very slowly because I'm trying to juggle work/family/development and docs all at the same time - sure everyone here knows the story ... |
||||||||
|
|
|||||||
Ooh, yeah. Almost forgot about that alignment thingy. Asked for that way back. Glad to see it. Ron, love the Rat Progressbar. |
||||||||
|
|
|||||||
Doc - glad you got a sense of humour ! Chris - I remember that discussion we had. Not too sure if you noticed or not - but I purposely re-arranged the proposed TextAlign enumerations to be different then the current Alignment enums. Alignment has only three values, like this: 0 - Left 1 - Right 2 - Centered and TextAlign starts like this: 0 - TopLeft 1 - TopCentered 2 - TopRight It would have been "better" imho to make the first three values of the new TextAlign property "line-up" with the old Alignment property ... just cause (i) memorized the settings ... but, I think the new TextAlign is more intuitive and easily remembered, one can visualize a 3x3 grid and the numbers lineup from left to right, top to bottom (know what I mean?). |
||||||||
|
|
|||||||
hmmm, guess the other way we could do it is to not have a new TextAlign property, and just simply extand the current Alignment property, but it would look like this: 0 - Left 1 - Right 2 - Centered 3 - MiddleLeft 4 - MiddleRight 5 - MiddleCentered 6 - BottomLeft 7 - BottomRight 8 - BottomCentered This would save me from having to allocate a new property ... plus its perfectly backward compatible with older scripts ... |
||||||||
|
|
|||||||
Good point, Shawn. That would be easier to remember. That's why I like you so much, yer always thinkin'. |
||||||||
|
|
|||||||
Go for it ! Don't see any problems in there |
||||||||
|
|
|||||||
Never mind, cant do it like that ... theres a new control coming in vers 2.3 that will need two seperate properties, one for TextAlign and one for ImageAlign ... |
||||||||
|
|
|||||||
I remember you talking about MemLeakFix... it's included in which version? |
||||||||
|
|
|||||||
Jooel, the memory leak is fixed. Will be in the next version - build 37. |
||||||||
|
|
|||||||
shawn, one question and one : how do I change font size in richtextbox? made it .fontsize=18 and got so small could not read it??? then, hyperlink does not accept &. nor it works with url encoded & |
||||||||
|
|
|||||||
Jooel, The RichTextBox aint finished yet, will start working on it again after the next release. In the meantime, might want to play with the embedded HTML support, just for a larf: code:Still much work to do on the parser, and the property will be changing from Text to Html, but you get the idea.$RichEdit.Text = ' |
||||||||
|
|
|||||||
uuh... so, could I have amp in the hyperlink? |
||||||||
|
|
|||||||
I will let you know when I get back to coding the RichTextBox control. Imagine so ... you can stick a link in now, ex: code:But the LinkClick isn't being triggered up-the-chain, the HTML is usefull for very basic, simple text formatting only. A usefull way to format the control without having to position the caret and change colors and fonts, etc ...<a href=http://www.kixtart.org>Kixtart Bulletin Board</a> [edit] crap, the bbs is interpreting the html. [ 25. November 2002, 22:36: Message edited by: Shawn ] |
||||||||
|
|
|||||||
not sure we are talking the same stuff in here $hyperlink=$form.hyperlink("me text & not show",5,5) |
||||||||
|
|
|||||||
ah ! thought you were talking about hyperlinks in RichTextBoxes ... hey man, what do we usually do around here when a single meta-char gets eaten within a string ? |
||||||||
|
|
|||||||
don't care? I've seen even kix to crash on a split when there is norwegian character in a string. like Ø |
||||||||
|
|
|||||||
Shawn, I know we talked about this before.. Is there a "tray" option coming for KixForms? Kent |
||||||||
|
|
|||||||
Kent, you know what ... I would love to have bbChecker running from the system tray as well. Having said that, lets makes this our first task after build 37 is released (shooting for this weekend). This would mean that I would have to work very closely with Jooel on this ... and you know what thats like ... working with those "artistic" types - lol -Shawn [ 26. November 2002, 16:41: Message edited by: Shawn ] |
||||||||
|
|
|||||||
m...mmm.... |