|
|
|||||||
Here is a sample script that Shawn wrote that demos the new TabControl. What is cool about this is that you can "reuse" variable names in this context without destroying the object. The magic is that each TabPage is indexed under the TabControl. Break On $Form = CreateObject("Kixtart.Form") $Form.FormBorderStyle = 4 $Form.ClientSize = 500,300 $TabControl = $Form.Controls.TabControl $TabControl.Size = $Form.ClientSize $TabControl.Anchor = 15 $TabControl.OnSelectedIndexChanged = "OnTabControlSelectedIndexChanged()" For $i = 0 to 20 $TabPage = $TabControl.TabPages.Add($i) $ListView = $TabPage.Controls.ListView $ListView.Size = $TabPage.ClientSize $ListView.Anchor = 15 $ListView.GridLines = 1 $ListView.Columns.Count = 10 For $j = 0 to 10 $Item = $ListView.Items.Add($j) For $k = 0 To $ListView.Columns.Count - 1 $Item.SubItems($k).Text = $k Next Next $ListView.Name = "ListView" $ListView.Tag = "This is listview #$i" Next $Form.Show While $Form.Visible $=Execute($Form.DoEvents) Loop Exit 1 Function OnTabControlSelectedIndexChanged() If $TabControl.SelectedIndex <> -1 $ListView = $TabControl.TabPages($TabControl.SelectedIndex).Controls("ListView") $Form.Text = $ListView.Tag EndIf EndFunction |
||||||||
|
|
|||||||
Chris, On this one, I get a 15 then a 1 on the console. After that, It quits. What is gonig on? Do I need a new version of Kixforms? |
||||||||
|
|
|||||||
The most likely reason is that you don't use the latest kixforms build that is build 40 aka. 2.3.0 Beta 2 get that here Hey, nice sample btw. [ 16. June 2003, 14:24: Message edited by: Jochen ] |
||||||||
|
|
|||||||
Yeah, sorry. I failed to mention that this sample requires the latest beta of KiXforms. |
||||||||
|
|
|||||||
Im Using KiXforms_230b3. Got "Runtime-error.The Form object does not support the Count property or method" What 2 do ? |
||||||||
|
|
|||||||
Sounds like your still not running the lastest version. When you regsvr32 the DLL, make sure to fully qualify the pathname, like this: regsvr32 c:\tools\kixforms.dll or whatever your path is. If you are able to get a form running, left click the app icon in top left corner of the title bar, and click "about..." - make sure the build is 2.3.0.41 ... -Shawn |
||||||||
|
|
|||||||
It is highly recommended to get in the habit of properly unregistering and re-registering DLL files. Yes you would probably not experience any issue with KiXforms DLL by just overwriting it, but the preferred method is to run Unregister regsvr32 /u kixforms.dll Register regsvr32 kixforms.dll That can be run from the RUN command on the start menu so only takes less then a second. Yes one can place a DLL in the installation folder, but that is not a best practice method. DLL files should be located in %WINDIR%\SYSTEM32 |
||||||||
|
|
|||||||
By not unregistering and re-registering a DLL properly, you will not be able to access new methods that are in the new DLL but not in the DLL that was previously registered. |
||||||||
|
|
|||||||
Both Doc and Howard are correct. The point being here is that with new functionality there are new "calls" to these new methods. They need to be regsistered to show. Kent |
||||||||
|
|
|||||||
heh. the unregister is only needed when the functionality is ripped out. as far as I understand how the reg is handled. anyway, with kixforms, can't try that... well, without registering a really old build over new one. |
||||||||
|
|
|||||||
COM Objects designed just for scripting purposes only are more forgiving to just overlaying the DLL and not re-registering. But when new functionality in terms of new objects are added, re-registering is a good thing and prob required. If just Automation methods and properties have been added, overlaying works ok (do it all the time). Like Jooel says, if objects have been ripped-out, un-registering should be done to clean up. But mostly that doesn't happen. |
||||||||
|
|
|||||||
But as an END USER of any software not written by ones self, you usually have no idea what the author has done inside the code behind the DLL. Thus, unregister, re-register (about 1 second of time) is much easier and should ensure less possibility of encountering an issue. |
||||||||
|
|
|||||||
Yes, just make it a "best practice" to un/re-register COM-DLLs if they've been changed. |
||||||||
|
|
|||||||
until you start to wrap up installers and selling your exe, that is NEVER a best-practise. why to do hard of an simple thing? everyone who ever uses dll in his script, as example, kixforms.dll, knows where is going. and if he/she ever does a package where he is unsure what is happening, he might do unreg/reg... but for about 99,99999999% it's unneeded. |