#95075 - 2002-11-01 05:36 AM
KixForms Comments/Observations/RFC
|
Kdyer
KiX Supporter
   
Registered: 2001-01-03
Posts: 6241
Loc: Tigard, OR
|
We have seen some amazing things come out with KixForms.DLL.
We must all show some appreciation of gratitude to Shawn for his developments efforts in building it.
Secondly, we should thank Lonkero (Jooel) for his work on BBChecker and BBCodeParser.
Observation If we look at the threads of BBChecker, we see literally hundreds of responses from people, so this appears to push the "hot buttons." No wonder, it offers a rich, user interface..
I have been thinking how to put this together, but here goes.
Creating a new form When developing a KixForms application, how do you know where to place the elements? I mean most people don't have the luxury of having Visual Studio or Microsoft Access to start designing a form. OK, for the sake of argument where do you start in the design process to put these things? Is just simply "trial and error?"
Thanks,
Kent
|
|
Top
|
|
|
|
#95076 - 2002-11-01 07:38 AM
Re: KixForms Comments/Observations/RFC
|
NTDOC
Administrator
   
Registered: 2000-07-28
Posts: 11628
Loc: CA
|
I agree
GREAT WORK Shawn and Joel
Both are very nice additions to the tools needed when working on all our systems.
Thanks again.
Kent, as far as I can tell it is trial and error.
Chris has created some of the more advanced samples that I've seen. What say you Chris? [ 01. November 2002, 07:39: Message edited by: NTDOC ]
|
|
Top
|
|
|
|
#95077 - 2002-11-01 07:40 AM
Re: KixForms Comments/Observations/RFC
|
Kdyer
KiX Supporter
   
Registered: 2001-01-03
Posts: 6241
Loc: Tigard, OR
|
Thinking about the fact that MCA is back.. It will be interesting to see the trends.
Kent
|
|
Top
|
|
|
|
#95079 - 2002-11-01 07:54 AM
Re: KixForms Comments/Observations/RFC
|
Kdyer
KiX Supporter
   
Registered: 2001-01-03
Posts: 6241
Loc: Tigard, OR
|
Hmmm..
Do I see a new task on the horizon?
<smile>
Kent
|
|
Top
|
|
|
|
#95080 - 2002-11-01 08:08 AM
Re: KixForms Comments/Observations/RFC
|
NTDOC
Administrator
   
Registered: 2000-07-28
Posts: 11628
Loc: CA
|
hmmm Kent is on but no AOL or MS
Lonkero... I updated my image again (temporarily) How you like the new one?
ps. Got your mail and script. Works fine. I'll look into setting it up on my site soon. [ 01. November 2002, 08:10: Message edited by: NTDOC ]
|
|
Top
|
|
|
|
#95084 - 2002-11-01 04:29 PM
Re: KixForms Comments/Observations/RFC
|
Chris S.
MM club member
   
Registered: 2002-03-18
Posts: 2368
Loc: Earth
|
Usually, as I build my forms it is by 'trial & error.' Occasionally, If I get stuck on a layout, I'll fire up VB6 and create a mock-up, but really you could do this with pen & paper if you wanted.
I try to keep all of the 'KiXforms' building at the top of the script for no other reason than that the forms have to be loaded into memory before you can show them.
Since building a form is dependent on the 'parent/child' objects I start out with the parent form. Then I generally start with the topmost 'Child,' such as a frame or picturebox. Then I follow with the children of those objects. Additional forms and object follow that until I have all of my form-work done. The order doesn't matter much, except that the parent must proceed the child and you can't set properties until the object is created.
Example of LogonScriptSmpl:
Form Root (never shown to prevent child forms from showing in taskbar) ...Form Logo ......<Form Logo has no children, just properties> ...Form Main ......Frame User .........Label Fullname .........Textbox Fullname .........Label Username .........Textbox Username .........Label Logon Server .........Textbox Logon Server .........Label Logon Domain .........Textbox Logon Domain ......Frame Status .........Label Status .........ProgressBar Staus ...Form Function Status ......Label Function Status ......ProgressBar Function Status
The script then is either fired off from the 'Do Events' loop or it just flows like a regular script.
Hope this helps.
|
|
Top
|
|
|
|
#95085 - 2002-11-01 04:43 PM
Re: KixForms Comments/Observations/RFC
|
Shawn
Administrator
   
Registered: 1999-08-13
Posts: 8611
|
Actually Kent, the question you pose (re: laying out forms) is good one. There are actually a couple of ways to do this. But the success of each one depends alot on the personal preferences and "mind set" of the individual:
1) TRIAL AND ERROR The "trial and error" approach is the most common - even with the more advanced methods that I will outline below, trial and error is still the key strategy. Simply code the form and guess-timate the location and size of all the controls, then run the script and check it out, then adjust your code then run again. When designing a form, one might have to run the script dozens upon dozens of times to get the right look-and-feel. The only other thing I can say about this strategy is that one should never try to code the entire form all at once. Start with one element of the form, get it to look right, then move on to the next.
2) VB FORM DESIGNER In terms of the way controls are constructed and configured, I tried to design Kixforms to be very similiar to VB and VB.NET. Having said that, one can even go so far as to design a form using Visual Studio, then take the generated .FRM file and copy it directly into ones script. Then manually "convert" all the statements over to Kixtart syntax. I've done this quite a bit in the past, when converting public domain VB source into Kixtart/Kixforms (ie, the MUD Manage User Details script). Here's some example VB6 .FRM statements:
code:
Begin VB.TextBox txtFullName Height = 285 Left = 3600 TabIndex = 15 Top = 1245 Width = 3450 End Begin VB.ListBox lstGroupPath Height = 255 Left = 6105 TabIndex = 24 Top = 4380 Visible = 0 'False Width = 855 End
Then just convert it to Kixforms:
code:
$txtFullName = $Form.TextBox $txtFullName.Height = 285/15 $txtFullName.Left = 3600/15 $txtFullName.TabIndex = 15 $txtFullName.Top = 1245/15 $txtFullName.Width = 3450/15 $lstGroupPath = $Form.ListBox $lstGroupPath.Height = 255/15 $lstGroupPath.Left = 6105/15 $lstGroupPath.TabIndex = 24 $lstGroupPath.Top = 4380/15 $lstGroupPath.Visible = 0 ; False $lstGroupPath.Width = 855/15
Why divide by 15 ? This converts VB twips into pixel units of measure. This excersize can be done using visual studio and DOTNET as well:
code:
this.listView1 = new System.WinForms.ListView (); listView1.Location = new System.Drawing.Point (40, 24); listView1.Size = new System.Drawing.Size (480, 168); listView1.FullRowSelect = true; listView1.View = System.WinForms.View.Report; listView1.ForeColor = System.Drawing.SystemColors.WindowText; listView1.GridLines = true; listView1.TabIndex = 0; this.addbutton = new System.WinForms.Button (); addbutton.Location = new System.Drawing.Point (320, 232); addbutton.Size = new System.Drawing.Size (56, 48); addbutton.TabIndex = 7; addbutton.Text = "Add"; addbutton.Click += new System.EventHandler (this.addbutton_Click);
and the Kixforms version:
code:
$listView1 = $Form.ListView() $listView1.Location = 40, 24 $listView1.Size = 480, 168 $listView1.FullRowSelect = true $listView1.View = 3 $listView1.ForeColor = Blue $listView1.GridLines = true $listView1.TabIndex = 1 $addbutton = $Form.Button() $addbutton.Location = 320, 232 $addbutton.Size = 56, 48 $addbutton.TabIndex = 7 $addbutton.Text = "Add" $addbutton.OnClick = "addbutton_Click"
3) And lastly, the style that I prefer, is to leverage the size and location of existing objects to build the form on the fly. The way this works to to use all the builtin Kixforms positioning and sizing properties to quickly acheive a form effect (ever wonder why there were SO MANY position and sizing methods in Kixforms - this is why)
So for example, what I do is picture how the form will look in my mind, then describe it using words (again, in my mind), example:
code:
The form will 600 pixels wide by 400 pixels in height. A listview will be positioned in the upper left corner of the form and extend halfway across the width and fully down to the bottom (less about 10 pixels for a border). Just to the right of the listview, will be a 100x30 button containing the word "Exit"
Then I code it as follows:
code:
Break On $Form = CreateObject("Kixtart.Form") $Form.Size = 600,400 $ListView = $Form.Listview $ListView.Location = 10,10 ; Upper left $ListView.Right = 0.5 * $Form.ClientWidth ; Half the width of the form $ListView.Bottom = $Form.ClientHeight - 10 ; All the way to the bottom $Button = $Form.Button $Button.Left = $ListView.Right + 10 ; Just to the right $Button.Top = $ListView.Top ; same as listview $Button.Size = 100,30 ; 100x30 $Button.Text = "Exit" ; The caption $Form.Center $Form.Show While $Form.Visible $=Execute($Form.DoEvents) Loop
Hope this give you the flavours of the mind processes that go on when designing forms. Look forward to your comments and thoughts.
-Shawn [ 02. November 2002, 21:23: Message edited by: Shawn ]
|
|
Top
|
|
|
|
#95086 - 2002-11-01 05:21 PM
Re: KixForms Comments/Observations/RFC
|
Shawn
Administrator
   
Registered: 1999-08-13
Posts: 8611
|
Chris, I see your on the same wave-length as I am You've got some really good pointers in there as well and I agree with them all.
Some other thoughts:
Im with Chris in terms of script layout. I like to keep all my form construction at the top of the script. It "looks" more like VB6 .FRM and VB.DOTNET when done like this.
I've been "playing" with event functions (UDF) position quite a bit and haven't decided on which postitioning strategy I like best.
1) Put all the event functions at the bottom of the script, after the DoEvents loop. (VB-like)
2) Put all the event functions right after (next to) the object construction statements for that object. This keeps them localized to the same area as the object.
Like I said, haven't picked a preference here yet - both have upsides and downsides. [ 01. November 2002, 17:22: Message edited by: Shawn ]
|
|
Top
|
|
|
|
#95087 - 2002-11-01 05:33 PM
Re: KixForms Comments/Observations/RFC
|
Kdyer
KiX Supporter
   
Registered: 2001-01-03
Posts: 6241
Loc: Tigard, OR
|
Shawn,
Thanks for your comments.
This process should/could be made simpler. What I am thinking is terms analogous to Microsoft FrontPage. This type of application is a "code-hog" from a Developer's perspective, but offers "ease-of-use." Most of us are extremely busy and deployment of forms-based applications could be delayed with the "trial-and-error" methods.
Thanks again,
Kent
|
|
Top
|
|
|
|
#95090 - 2002-11-01 06:07 PM
Re: KixForms Comments/Observations/RFC
|
Kdyer
KiX Supporter
   
Registered: 2001-01-03
Posts: 6241
Loc: Tigard, OR
|
Shawn,
Now that I go back and re-read your response. It makes perfect sense to me. Especially Option #3.
Thanks,
Kent
|
|
Top
|
|
|
|
Moderator: Arend_, Allen, Jochen, Radimus, Glenn Barnas, ShaneEP, Ruud van Velsen, Mart
|
1 registered
(Allen)
and 1198 anonymous users online.
|
|
|