|
|
|||||||
I think I have found a bug in Kixforms for the FileOpenDialog() method. I have noticed that sporadic behavor from this method. It will let me open files anywhere from 1 to as many as 7 times and then, POOF, the scripts quits with no error code. Is this a known issue that I have missed or am I doing something wrong? code:OutputFUNCTION Open_Click() code:ThanksC:\Programs\Kix\kixforms\RTA\removeclient.lst |
||||||||
|
|
|||||||
My gut feeling is that I still don't have that FILTER parameter working quite right yet. Krabourn, just as a test, can you null-out ("") the filter parm and run your tests again to see if it still craps out ? |
||||||||
|
|
|||||||
It still dies. code:$Form.FileOpenDialog('Open Computer List', '.\', 'COMPUTER.LST','') |
||||||||
|
|
|||||||
Try putting an extra parm set to zero at the end, exmaple: $FileName = $Form.FileOpenDialog('Open Computer List', '.\', 'COMPUTER.LST','',0) Same ? |
||||||||
|
|
|||||||
I can't verify this behavior. Could it be something else? |
||||||||
|
|
|||||||
Speaking of the FileOpenDialog...is it possible to have a default flag of '4' to mask the 'Open as read-only' checkbox? As far as I know, we don't have a way of checking if that checkbox is checked anyway. |
||||||||
|
|
|||||||
Still a no go. code:Shawn:$Form.FileOpenDialog('Open Computer List', '.\', 'COMPUTER.LST', '', 0) I forgot to mention. I am using the build that you sent me. The DLL is dated 11/5/2002. Just in case. |
||||||||
|
|
|||||||
I'm using that same build, but still can't reproduce the error. |
||||||||
|
|
|||||||
Microsoft Windows 2000 [Version 5.00.2195] Kix32 4.12 (Final) Kixforms 11/5/2002 |
||||||||
|
|
|||||||
krabourn, I think it has to be something else causing the script to quit. Your example output is showing that the operation has completed successfully and then exits. Or...is it crapping out the next time you call the function? Try putting a 'debug on' in your function to verify. |
||||||||
|
|
|||||||
I have tried Debug and that does not help. I can remark out the FileOpenDialog() line and everyhting works fine. I have tried Kix 4.11 through 4.12. I also took the spaces out after the commas and that did not help. I guess I am getting desparate. |
||||||||
|
|
|||||||
Is the script acutally trapping (ie, theres an eventlog exception) or is it just not performing the Dialog ? |
||||||||
|
|
|||||||
I was wr.. wr.. wrong. Taking the spaces out did help. [ 13. November 2002, 20:46: Message edited by: krabourn ] |
||||||||
|
|
|||||||
Chris, I hear you buddy, I've been doing some strategizing of late in terms of a better (more dotnet-like) approach to the Common Dialogs. It is a mistake to treat them as simple method calls - they should be seperate stand-alone objects in their own right. Having said that, what I propose is something like the following: Instantiate the OpenFileDialog as a seperate object at the top of one's script: code:and then to invoke the dialog: code:Then, I can move to implement a more robust versions of all the following: BrowseForFolderDialog, FileCopyDialog, PrintDialog, ColorDialog and FontDialog.If $OpenFileDialog.ShowDialog() = 1 ; OK Any thoughts ? |
||||||||
|
|
|||||||
Shawn, I dig it, baby. I think that is a shagadellic idea. |
||||||||
|
|
|||||||
Of course, this will change the under-the-covers landscape of Kixforms a little bit. Remember how we were talking about bypassing regsvr32 and poking the registry directly - this may get trickier in this new scenario - but no big deal because I'm planning on implementing two new major Kixforms classes anyway. In the registry, Kixforms is under HKEY_CLASSES_ROOT with the key: Kixtart.Form well, there will be two more (in the short-term anyways): Kixtart.Form Kixtart.Dialog Kixtart.Graphics These will make their appearance in up-comming builds. They won't be directly accessible through code however - they will just be containers for a ton of new objects in works. Kixtart.Dialog will contain all the new Dialog classes we just discussed. Kixtart.Graphics will contain a set of objects used for rendering. For example: the following classes: Icon Bitmap Image (the base class for Icon and Bitmap) and a bunch of rendering methods, some of which are: DrawImage DrawPoly DrawArc DrawRectangles DrawGradientFill [ 13. November 2002, 22:06: Message edited by: Shawn ] |
||||||||
|
|
|||||||
Therein lies the danger of bypassing the 'usual' install. |
||||||||
|
|
|||||||
hmm ... now I am a bit disconcerted What does the implementation of that classes imply for the programmer ? Do we have to Create those as additional objects or are they accessed by Kixtart.form anyway ? Do we have to preceed subsequent calls of objects in these with Form.Dialog(Graphics).Object ? (Don't think so after re-reading) Please clarify J. |
||||||||
|
|
|||||||
j, can't be 100,1% sure but there has been lot of stuff in reg before and those had "nothing" to do with the usage. if I understood your question... shawn, what you mean with bypassing regsvr32?   |
||||||||
|
|
|||||||
Jochen, quote:Good question. In the case of the Common Dialogs, haven't really decided yet ... but lets talk about the Graphics classes first. They will be accessed through Kixtart.Form something like this (for example, to create a bitmap): code:Then, lets say you wanted to draw the bitmap$Bitmap = $Form.Graphics.Bitmap(".\kixtart.bmp") somewhere on a form, like this: code:All graphics objects would be accessed and$Form.Graphics.DrawImage($Bitmap,10,10) manipulated through the Graphics property of any class that supported graphics (right now, only a handfull). The Common Dialogs are a different story. Two options here. One is to instantiate the dialogs seperately using CreateObject like this: code:or, the other way is to instantiate through a$Dialogs = CreateObject("Kixtart.Dialogs") property called Dialogs in all Kixtart.Form classes like this: code:Any thoughts on the best approach here ?$OpenFileDialog = $Form.Dialogs.OpenFileDialog() Jooel, yeah - think you might have been on vacation when we discussed bypassing regsvr32 to register Kixforms, and just use registry pokes. And - when a new build of Kixforms is released - simply copy over the existing DLL and not re -register the component. This is an OK thing to do, as long as none of the underlying COM classes have been changed. Which WILL be the case when these two new major classes are released. Once its re-registered, then one can go back to simply copying over the DLL. But Les's point about bypassing regsvr32 is valid. |