From: Wolfgang W. <wol...@we...> - 2012-12-19 11:37:55
|
Hi, It looks like the size of files with more than 4294967295 bytes isn't returned correctly by Rexx Utility SYSFILETREE. Wolfgang |
From: Mark M. <mie...@gm...> - 2012-12-19 14:35:47
|
On Wed, Dec 19, 2012 at 3:37 AM, Wolfgang Westphal <wol...@we...> wrote: > It looks like the size of files with more than 4294967295 bytes isn't > returned correctly by Rexx Utility SYSFILETREE. That's correct. Due to backwards compatibility restraints, the size of the field can not be extended. The File class supports greater than 4 GB file sizes. -- Mark Miesfeld |
From: Art H. <art...@ar...> - 2012-12-19 17:02:02
|
It appears with the latest release of oodialog, the NumberOnlyEditEx.cls causes duplicate key strokes to be entered - if you backspace one character, two characters are removed, if you enter one digit, the digit is duplicated. The samples\oodialog\userGuide\exercises\Exercise05 shows the problem when the Product List Price or UOM fields are updated. Let me know if I should open a bug report, and how to do that, if needed. Thanks.. -- Art Heimsoth - art...@ar... |
From: Mark M. <mie...@gm...> - 2012-12-19 17:08:47
|
On Wed, Dec 19, 2012 at 9:01 AM, Art Heimsoth <art...@ar...> wrote: > It appears with the latest release of oodialog, the NumberOnlyEditEx.cls > causes duplicate key strokes to be entered - if you backspace one character, > two characters are removed, if you enter one digit, the digit is duplicated. > The samples\oodialog\userGuide\exercises\Exercise05 shows the problem > when the Product List Price or UOM fields are updated. Let me know if I > should open a bug report, and how to do that, if needed. Thanks.. Yes Art, there is that bug. Normally I'd say just open a bug, but one has already been opened: #1150 connectCharEvent for edit control places double digits in edit field I rebuilt the beta and put the fixed version on SourceForge if you want to try it. Thanks for bringing this up. Please open a bug report if you find anything else. -- Mark Miesfeld |
From: Art H. <art...@ar...> - 2012-12-19 21:27:05
|
> On Wed, Dec 19, 2012 at 9:01 AM, Art Heimsoth > <art...@ar...> wrote: > >> It appears with the latest release of oodialog, the >> NumberOnlyEditEx.cls causes duplicate key strokes to be entered - >> if you backspace one character, two characters are removed, if >> you enter one digit, the digit is duplicated. The >> samples\oodialog\userGuide\exercises\Exercise05 shows the problem >> when the Product List Price or UOM fields are updated. Let me >> know if I should open a bug report, and how to do that, if >> needed. Thanks.. >> > > Yes Art, there is that bug. Normally I'd say just open a bug, but > one has already been opened: > > #1150 connectCharEvent for edit control places double digits in > edit field > > I rebuilt the beta and put the fixed version on SourceForge if you > want to try it. > > Thanks for bringing this up. Please open a bug report if you find > anything else. > > -- > Mark Miesfeld > How do I find the beta version with the fix? I found the Bugs report #1150 but did not find a link to allow me to download the Windows version. -- Art Heimsoth - art...@ar... |
From: Mark M. <mie...@gm...> - 2012-12-19 21:44:55
|
On Wed, Dec 19, 2012 at 1:26 PM, Art Heimsoth <art...@ar...> wrote: >> I rebuilt the beta and put the fixed version on SourceForge if you >> want to try it. >> > How do I find the beta version with the fix? I found the Bugs > report #1150 but did not find a link to allow me to download > the Windows version. You download it from SourceForge, from the same place you downloaded the original beta: https://sourceforge.net/projects/oorexx/files/ooDialog/4.2.1.beta/ ooDialog-4.2.1.8713-x86_64.exe ooDialog-4.2.1.8713-x86_32.exe The 8713 in the name is the svn revision number. In the bug report it says: Committed revision 8710. [r8710] 4.2.1 branch So any build later than revision 8710 would have the fix in it. So, 8713 includes the fix. Or you could have just gone to the file download area and got the latest ooDialog 4.2.1 package. With the latest meaning the package with the highest revision number. -- Mark Miesfeld |
From: Art H. <art...@ar...> - 2012-12-24 03:26:02
|
I have a test case that shows this problem, but did not want to send it to the list. I have a dialog with up to 9 rows (plus other fields) each row containing a combination of date, text and numeric fields. There are 6 entry fields in each row, and each row is only displayed if there is data (from a SQL database or based on calculations). There are multiple numeric fields using the NumberOnlyEditEx class, each with different decimal positions and different sizes. The dialog symbols are using stem variables, as are the variables for each edit field. For example, the initialization of the numeric field that is appearing incorrectly is: /* Ticket sold dollar amount is numeric, 2 decimals, no sign */ TktDoll.i = self~newEdit(IDC.Doll.1) TktDoll.i~initDecimalOnly(2, .false) TktDoll.i~connectCharEvent(onChar) TktDoll.i~setLimit(8) TktDoll.i~TabStop(.TRUE) self~connectEditEvent(IDC.Doll.i,LOSTFOCUS, focusDOLL.i) where the IDC.DOLL.i and focusDOLL.i are defined as IDC.Doll.i = "IDC_TKT_DOLL" || i focusDOLL.i = "OnLostFocusDOLL" || i with i being stepped in a do loop earlier in the InitDialog method, and the IDC. and focusDOLL. and TktDoll. stems are exposed in the methods that use them. According to my traces, when the TktDoll.1 Edit field is set to a value, all of the TktDoll.x Edit fields are set to the same value. The show and hide operations also seem to cause the incorrect row's Edit field to display or be hidden. This last issue does not show up in the test case. I have not tried to remove the stem usages for the symbolic references, but can do that if it is felt this is contributing to the problem. Any ideas? -- Art Heimsoth - art...@ar... |
From: Mark M. <mie...@gm...> - 2012-12-24 03:48:06
|
On Sun, Dec 23, 2012 at 7:25 PM, Art Heimsoth <art...@ar...> wrote: > I have a test case that shows this problem, but did not want to send it > to the list. Hi Art, I don't have any real good ideas. See below. > I have a dialog with up to 9 rows (plus other fields) each row containing a > combination of date, text and numeric fields. There are 6 entry fields in > each row, and each row is only displayed if there is data (from a SQL > database or based on calculations). There are multiple numeric fields > using the NumberOnlyEditEx class, each with different decimal positions > and different sizes. The dialog symbols are using stem variables, as are > the variables for each edit field. For example, the initialization of the > numeric field that is appearing incorrectly is: > /* Ticket sold dollar amount is numeric, 2 decimals, no sign */ > TktDoll.i = self~newEdit(IDC.Doll.1) IDC.Doll.1 above doesn't look right. Is that "one" meant to be an 'i'? It looks on the face of it that you are using the same resource ID for each edit field? That won't work of course. You can always send your test case directly to me. It is difficult for me to say without being able to run the program. -- Mark Miesfeld |
From: Art H. <art...@ar...> - 2012-12-27 23:42:34
|
I am trying to capture the content of an Edit field before the dialog user's entry character changes it. I am using a combination of GotFocus and Update events - the onGotFocus method to determine when that field has the focus, and then the Update method to actually detect the field is being changed. I am trying at that point to retrieve the field content with getText but want it *before* the keypress has actually changed the data. It appears to always be *after* the change has been made. I do not want to enter the Update method when the user is simply tabbing over the field, or before they attempt to entry data into it. Is this possible? Code fragment.. self~connectEditEvent(IDC_EditFieldName1, UPDATE, onFieldName1) self~connectEditEvent(IDC_EditFieldName1, GOTFOCUS, onGotFocusName1) ... ... ::method onGotFocusName1 -- set switch to indicate user has set focus to field, to not get the data -- when it is being initialized/changed by the dialog program ::method onFieldName1 -- if Name1 field switch indicates it has focus, then -- get Name1 field data .. at this point, the field always has the changed data. -- Art Heimsoth - art...@ar... |
From: Mark M. <mie...@gm...> - 2012-12-28 00:24:28
|
On Thu, Dec 27, 2012 at 3:42 PM, Art Heimsoth <art...@ar...> wrote: > I am trying to capture the content of an Edit field before the dialog user's > entry character changes it. I am using a combination of GotFocus and > Update events - the onGotFocus method to determine when that field has > the focus, and then the Update method to actually detect the field is being > changed. I am trying at that point to retrieve the field content with getText > but want it *before* the keypress has actually changed the data. It appears > to always be *after* the change has been made. Yes, the UPDATE event notification is always going to be after the user has typed a key. I think you should just use the GOTFOCUS event. > I do not want to enter > the Update method when the user is simply tabbing over the field, or > before they attempt to entry data into it. I don't quite understand why it makes a difference? Each time the edit control gets the focus, save the current text. If the user is simply tabbing over the edit control, so what? The next time the user sets focus to the edit control, save the text again. Sure it will be the save text you saved the previous time, but there is no down-side to it. It will not slow your program down or anything like that. > Is this possible? You would need to use the connectCharEvent() instead of connecting the UPDATE event. Set a flag in the got focus handler, say noCharsYet and maybe another, didGetFocus. In the character event handler, if didGetFocus and noCharsYet save the edit control text; set noCharsYet to false, and return .true always from the handler so that the character is passed on to the edit control. Connect the lost focus event to change the didGetFocus flag. Not sure if you will need all of that or not. Depends on exactly what you are trying to do... > Code fragment.. -- This has to be after the underlying dialog exists: self~new(IDC_EditFieldName1)~connectCharEvent(onCharFieldName1) self~connectEditEvent(IDC_EditFieldName1, LOSTFOCUS, onLostFocusFieldName1) self~connectEditEvent(IDC_EditFieldName1, GOTFOCUS, onGotFocusName1) > ... > ... ::method onGotFocusName1 expose noCharsYet didGetFocus noCharsYet = .false didGetFocus = .true ::method onCharFieldName1 expose noCharsYet didGetFocus saveTextFieldName1 use arg char, isShift, isCtrl, isAlt, misc, editCtrl if didGetFocus then do if noCharsYet then do saveTextFieldName1 = editCtryl~getText noCharsYet = .false end end return .true ::method onLostFocusFieldName1 expose didGetFocus didGetFocus = .false ... That should essentially do what you are asking. I'm not really sure whether the didGetFocus flag fits with what you need or not. You might want to play with it a bit to refine it. -- Mark Miesfeld |
From: Art H. <art...@ar...> - 2012-12-27 23:50:27
|
I am trying to use a Data Class to pass data between a mother and child dialog, where the ::attribute contains a stem variable. I have not found how to do this, but if I put a non-stem variable in the statements, it seems to work - so I think I have the dialogs, methods, class and attribute statements correct. A second part of this is, can I somehow use methods that are located in the mother dialog, from the child dialog? I would like to keep from replicating several of the common methods that are already in use in the mother dialog, from having to duplicate the code in the children dialogs. If so, are the exposed variables in the mother dialogs then from the mother variable pool or from the child's pool? Does this make sense? -- Art Heimsoth - art...@ar... |
From: Mark M. <mie...@gm...> - 2012-12-28 00:45:52
|
On Thu, Dec 27, 2012 at 3:50 PM, Art Heimsoth <art...@ar...> wrote: > I am trying to use a Data Class to pass data between a mother > and child dialog, where the ::attribute contains a stem variable. > I have not found how to do this, but if I put a non-stem > variable in the statements, it seems to work - so I think I have > the dialogs, methods, class and attribute statements correct. It will work, although if you are having problems using a stem variable, I would consider using some other type of object than a stem. Use a Directory object in place of a stem. But, if you are determined to use a stem you probably need to do something like this: ::class Parent class ::method dataPassingMethod data.value1 = 14 data.value2 = 'Tom' obj = .MyClass~new(...) obj~data = data. ::class MyClass ::attribute data ::method someMethod stm. = self~data say 'Name is:' stm.value2 say 'Number is:' stm.value1 The above will let you use a stem the way you are probably used to using a stem. Of course you could always use the [] syntax to access the stem, something like: ::class Parent class ::method dataPassingMethod data.value1 = 14 data.value2 = 'Tom' obj = .MyClass~new(...) obj~data = data. ::class MyClass ::attribute data ::method someMethod name = self~data[value2] age = self~data[value1] Recall that when you use the [] to access the tails, it is case sensitive. So I purposefully did not quote the value1 or value2. > A second part of this is, can I somehow use methods that are > located in the mother dialog, from the child dialog? If they are public methods you can. > I would > like to keep from replicating several of the common methods > that are already in use in the mother dialog, from having to > duplicate the code in the children dialogs. Using a variation of my above code: ::class Parent class ::method printSecret expose secret say secret ::method dataPassingMethod data. = <set up your data in the stem> obj = .MyClass~new(...) obj~data = data. obj~parent = self ::class MyClass ::attribute data ::attribute parent ::method someMethod stm. = self~data self~parent~printSecret > If so, are the > exposed variables in the mother dialogs then from the mother > variable pool or from the child's pool? Does this make sense? What you want to do makes sense. If you have a reference to any object, you can invoke methods in that object as long as they are public. If you make a reference to the parent dialog available to the child dialog, then the child can invoke any public method in the parent. The variable pool part of the question probably indicates a little confusion on your part. The exposed variables in the parent dialog are only available in the parent, and the same thing in the child. But when you invoke a method in the parent, that method will be running in the context of the parent, so the method has access to its exposed variables. It doesn't have access to any exposed methods in the child. -- Mark Miesfeld |
From: Art H. <art...@ar...> - 2012-12-28 04:01:57
|
> On Thu, Dec 27, 2012 at 3:50 PM, Art Heimsoth > <art...@ar...> wrote: > >> I am trying to use a Data Class to pass data between a mother and >> child dialog, where the ::attribute contains a stem variable. I >> have not found how to do this, but if I put a non-stem >> variable in the statements, it seems to work - so I think I have >> the dialogs, methods, class and attribute statements correct. >> > > It will work, although if you are having problems using a stem > variable, I would consider using some other type of object than a > stem. Use a Directory object in place of a stem. > > But, if you are determined to use a stem you probably need to do > something like this: > > ::class Parent class > > ::method dataPassingMethod > > data.value1 = 14 > data.value2 = 'Tom' > > obj = .MyClass~new(...) > obj~data = data. > > ::class MyClass > > ::attribute data > > ::method someMethod > The below statements cleared it up for me. I had the statements setup incorrectly. > stm. = self~data > say 'Name is:' stm.value2 > say 'Number is:' stm.value1 > Thanks much, that is now working for me. > >> A second part of this is, can I somehow use methods that are >> located in the mother dialog, from the child dialog? >> > > If they are public methods you can. > >> I would >> like to keep from replicating several of the common methods that >> are already in use in the mother dialog, from having to duplicate >> the code in the children dialogs. >> > > Using a variation of my above code: > > ::class Parent class > > ::method printSecret > expose secret > > say secret > > ::method dataPassingMethod > > data. = <set up your data in the stem> > > obj = .MyClass~new(...) > obj~data = data. > obj~parent = self > > ::class MyClass > > ::attribute data > ::attribute parent > > ::method someMethod > > stm. = self~data > self~parent~printSecret > Okay, this also appears to be working except for when I attempt to execute a method from the OK method in the child. I am using SQL in the child InitCode method okay, and a log method in the setup of the data, where the log method is in the mother and the execution of it is in the child method (someMethod) in your example. Those both work okay. When I attempt to execute the same log method from the OK in the child, the dialog seems to not respond anymore until I "X" out of the child dialog. Using Say statements I have verified the log method is NOT entered, but everything up to the execution of the self~parent~log("message") is working. Is there something special about the OK method in this case? >> If so, are the >> exposed variables in the mother dialogs then from the mother >> variable pool or from the child's pool? Does this make sense? >> > > What you want to do makes sense. If you have a reference to any > object, you can invoke methods in that object as long as they are > public. If you make a reference to the parent dialog available to > the child dialog, then the child can invoke any public method in > the parent. > > The variable pool part of the question probably indicates a little > confusion on your part. The exposed variables in the parent dialog > are only available in the parent, and the same thing in the child. > But when you invoke a method in the parent, that method will be > running in the context of the parent, so the method has access to > its exposed variables. It doesn't have access to any exposed > methods in the child. > Thanks, yes, I did have a misunderstanding of how it was handled. This clears it up for me. > -- > Mark Miesfeld > > -------------------------------------------------------------------- > ---------- Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web > API and much more. Get web development skills now with LearnDevNow - > 350+ hours of step-by-step video tutorials by Microsoft MVPs and > experts. SALE $99.99 this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122812 > _______________________________________________ Oorexx-users > mailing list Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-users -- Art Heimsoth - art...@ar... |
From: Mark M. <mie...@gm...> - 2012-12-28 04:24:19
|
On Thu, Dec 27, 2012 at 8:01 PM, Art Heimsoth <art...@ar...> wrote: >> On Thu, Dec 27, 2012 at 3:50 PM, Art Heimsoth >> <art...@ar...> wrote: > Okay, this also appears to be working except for when I attempt to > execute a method from the OK method in the child. I am using > SQL in the child InitCode method okay, and a log method in the > setup of the data, where the log method is in the mother and the > execution of it is in the child method (someMethod) in your example. > Those both work okay. When I attempt to execute the same log > method from the OK in the child, the dialog seems to not respond > anymore until I "X" out of the child dialog. Which dialog doesn't seem to respond? The parent or the child? > Using Say statements > I have verified the log method is NOT entered, but everything up > to the execution of the self~parent~log("message") is working. > Is there something special about the OK method in this case? There shouldn't be anything special about the Ok method, that I can think of. You might have a guarded method problem, but I can't say what. I.e. some method is guarded and can not run. How do you start the child dialog? I.e., do you use execute() or popupAsChild() or ... ? What does the method in your parent that starts the child look like? Is it guarded? The things I think of that might stop it from executing would seem to prevent it from executing in your other call to the method. Since that apparently works, I can't say. -- Mark Miesfeld |
From: Art H. <art...@ar...> - 2012-12-28 15:29:54
|
> On Thu, Dec 27, 2012 at 8:01 PM, Art Heimsoth > <art...@ar...> wrote: > >>> On Thu, Dec 27, 2012 at 3:50 PM, Art Heimsoth >>> <art...@ar...> wrote: >>> >> Okay, this also appears to be working except for when I attempt >> to execute a method from the OK method in the child. I am using >> SQL in the child InitCode method okay, and a log method in the >> setup of the data, where the log method is in the mother and the >> execution of it is in the child method (someMethod) in your >> example. Those both work okay. When I attempt to execute the >> same log method from the OK in the child, the dialog seems to not >> respond anymore until I "X" out of the child dialog. >> > > Which dialog doesn't seem to respond? The parent or the child? The parent is blocked and beeps when attempting to click on anything within it. The child accepts the Ok click, but nothing happens until I cancel it with the windows "X" - then all the pending actions for the Ok method continue. > >> Using Say statements >> I have verified the log method is NOT entered, but everything up >> to the execution of the self~parent~log("message") is working. Is >> there something special about the OK method in this case? >> > > There shouldn't be anything special about the Ok method, that I can > think of. You might have a guarded method problem, but I can't say > what. I.e. some method is guarded and can not run. > > How do you start the child dialog? I.e., do you use execute() or > popupAsChild() or ... ? What does the method in your parent that > starts the child look like? Is it guarded? The things I think of > that might stop it from executing would seem to prevent it from > executing in your other call to the method. Since that apparently > works, I can't say. The child is started with the execute().. parent method that starts it is simply "::method Doname" with one passed argument. It does a check and then creates the dialog with "dlg = .SelectDialog~new(..." loads the data class attributes and then does the execute(). It probably is something I have somewhere else, but I have moved the method executions out of the Ok method and the child dialog is working okay for me now. Thanks for thinking about it, if I find something more, I will let you know. Or if there is a way for me to find out what is blocking things, let me know and I can try that. > > -- > Mark Miesfeld > > -------------------------------------------------------------------- > ---------- Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web > API and much more. Get web development skills now with LearnDevNow - > 350+ hours of step-by-step video tutorials by Microsoft MVPs and > experts. SALE $99.99 this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122812 > _______________________________________________ Oorexx-users > mailing list Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-users -- Art Heimsoth - art...@ar... |
From: Mark M. <mie...@gm...> - 2012-12-28 17:17:59
|
On Fri, Dec 28, 2012 at 7:29 AM, Art Heimsoth <art...@ar...> wrote: >> On Thu, Dec 27, 2012 at 8:01 PM, Art Heimsoth >> <art...@ar...> wrote: >> >>>> On Thu, Dec 27, 2012 at 3:50 PM, Art Heimsoth >>>> <art...@ar...> wrote: >>>> >>> Okay, this also appears to be working except for when I attempt >>> to execute a method from the OK method in the child. I am using >>> SQL in the child InitCode method okay, and a log method in the >>> setup of the data, where the log method is in the mother and the >>> execution of it is in the child method (someMethod) in your >>> example. Those both work okay. When I attempt to execute the >>> same log method from the OK in the child, the dialog seems to not >>> respond anymore until I "X" out of the child dialog. >>> >> >> Which dialog doesn't seem to respond? The parent or the child? > > The parent is blocked and beeps when attempting to click on anything > within it. The child accepts the Ok click, but nothing happens until I > cancel it with the windows "X" - then all the pending actions for the > Ok method continue. Art, Here is a simple parent / child dialog that will behave as you describe above: /* Parent Dialog */ dlg = .SimpleDialog~new dlg~execute("SHOWTOP", IDI_DLG_OOREXX) ::requires "ooDialog.cls" ::class 'SimpleDialog' subclass UserDialog ::method init forward class (super) continue self~create(30, 30, 257, 123, "Parent Dialog", "CENTER") ::method defineDialog self~createPushButton(100, 10, 99, 50, 14, , "Test", onTest) self~createPushButton(IDOK, 142, 99, 50, 14, "DEFAULT", "Ok") self~createPushButton(IDCANCEL, 197, 99, 50, 14, , "Cancel") ::method log use arg msg say msg ::method onTest dlg = .ChildDialog~new dlg~data = 'not finished' dlg~parent = self dlg~execute("SHOWTOP", IDI_DLG_OOREXX) /* Child dialog */ ::class 'ChildDialog' subclass UserDialog ::attribute data ::attribute parent ::method init forward class (super) continue self~create(30, 30, 257, 123, "Child Dialog", "CENTER") ::method defineDialog self~createPushButton(IDOK, 142, 99, 50, 14, "DEFAULT", "Ok") self~createPushButton(IDCANCEL, 197, 99, 50, 14, , "Cancel") ::method ok self~parent~log('in okay') self~data = 'finished' self~parent~log('set data to finished') self~parent~log('quitting now') return self~ok:super The reason it will block when you press ok is that the parent dialog is executing in the onTest() method, which is guarded. The log() method in the parent dialog is also guarded. So when you invoke log() in child dialog's ok() method, the log() method can not run, because it is guarded and can not gain access to the dialog's variable pool. It can not run until the onTest() method finishes. A simple change that fixes this is to make log() unguarded. ::method log unguarded use arg msg say msg This doesn't explain, to me, your statement that moving the method invocations out of the ok() method allows things to work. I'd have to see your whole program to understand that. The other thing that you may not be aware of, is that when you start the child dialog using execute(), it gets started as a modal dialog. The parent dialog's user interface is disabled in this case. That is why you hear the beep. Now, you may or may not want, the child dialog to be modal. Normally you use a modal dialog because you do not want the user to be able to interact with the parent dialog until the user finishes with the child dialog. If you do want the user to be able to use the parent dialog, you should start the child dialog with the popup() or popupAsChild() method. This change will also work: ::method log use arg msg say msg ::method onTest dlg = .ChildDialog~new dlg~data = 'not finished' dlg~parent = self dlg~popUpAsChild(self, "SHOWTOP", IDI_DLG_OOREXX) If you notice I left the log() method guarded. This works because the popupAsChild() method returns immediately, so the onTest() method is not executing when you press Ok in the child. And finally, the alternative to making the log() method unguarded would be to make the onTest() method unguarded. This change will also work: ::method log use arg msg say msg ::method onTest unguarded dlg = .ChildDialog~new dlg~data = 'not finished' dlg~parent = self dlg~execute("SHOWTOP", IDI_DLG_OOREXX) -- Mark Miesfeld |
From: Art H. <art...@ar...> - 2012-12-28 18:40:42
|
> On Fri, Dec 28, 2012 at 7:29 AM, Art Heimsoth > <art...@ar...> wrote: > >>> On Thu, Dec 27, 2012 at 8:01 PM, Art Heimsoth >>> <art...@ar...> wrote: >>> >>>>> On Thu, Dec 27, 2012 at 3:50 PM, Art Heimsoth >>>>> <art...@ar...> wrote: >>>>> >>>> Okay, this also appears to be working except for when I >>>> attempt to execute a method from the OK method in the child. >>>> I am using SQL in the child InitCode method okay, and a log >>>> method in the setup of the data, where the log method is in >>>> the mother and the execution of it is in the child method >>>> (someMethod) in your example. Those both work okay. When I >>>> attempt to execute the same log method from the OK in the >>>> child, the dialog seems to not respond anymore until I "X" >>>> out of the child dialog. >>>> >>>> >>> Which dialog doesn't seem to respond? The parent or the child? >>> >> The parent is blocked and beeps when attempting to click on >> anything within it. The child accepts the Ok click, but nothing >> happens until I cancel it with the windows "X" - then all the >> pending actions for the Ok method continue. >> > > The reason it will block when you press ok is that the parent > dialog is executing in the onTest() method, which is guarded. The > log() method in the parent dialog is also guarded. > > So when you invoke log() in child dialog's ok() method, the log() > method can not run, because it is guarded and can not gain access > to the dialog's variable pool. It can not run until the onTest() > method finishes. > > > A simple change that fixes this is to make log() unguarded. > Okay, is there a place where the actions of guarded (which I assume it the default) and unguarded are relative to a method? From your description here, in my words, guarded/unguarded is dealing with serialization of the dialog's variable pool, where if a method is guarded, no other method can gain access to the variable pool for that dialog and will be blocked when another method is started within that same dialog. Also the execute() will keep the containing method active until the executed dialog ends. Is this correct and are there other implications of using unguarded; ie, are any variables protected from modifications performed by other methods while a given method is unguarded and active? I have never understood the guarded/unguarded operation and do not know the rules for usage. Thanks again for your great teaching help. I really appreciate it. -- Art Heimsoth - art...@ar... |
From: Mark M. <mie...@gm...> - 2013-01-01 00:18:41
|
Hi Art, I just realized that I never replied to this last message of yours: On Fri, Dec 28, 2012 at 10:18 AM, Art Heimsoth <art...@ar...>wrote: > From your description here, in my words, guarded/unguarded > is dealing with serialization of the dialog's variable pool, where > if a method is guarded, no other method can gain access to the > variable pool for that dialog and will be blocked when another > method is started within that same dialog. Essentially correct. When a guarded method is executing, if another guarded method is invoked, then that second guarded method will block. Another unguarded method will not block. By the way, this is basic ooRexx behavior, not something special to ooDialog. It is explained in the rexxref.pdf doc. Explained in the method directive section under an explanation of the guarded keyword. And in the section on concurrency. The other thing is, when a guarded method is executing, from within that method, invocations of other guarded methods do not block. > Also the execute() > will keep the containing method active until the executed dialog > ends. Sort of. But, it is not so much that execute() keeps the containing method active. It is do to the fact that execute() does not return until the underlying Windows dialog is ended. > Is this correct and are there other implications of using > unguarded; ie, are any variables protected from modifications > performed by other methods while a given method is unguarded > and active? > > Essentially correct, and yes there are implications. Object variables are no longer protected. > Okay, is there a place where the actions of guarded (which I > assume it the default) and unguarded are relative to a method? I'm not sure if I understand that question. Yes guarded is the default. Guarded and unguarded methods are relative to the object, not relative to a single method. > I have never understood the guarded/unguarded operation and > do not know the rules for usage. I don't have any simple 3 sentence rules for usage. Most of my knowledge is merely, this works, this doesn't work, play around with my code until what I want to happen, happens, type of thing. ;-) -- Mark Miesfeld |
From: Wolfgang W. <wol...@we...> - 2012-12-20 04:02:53
|
Thank you for your explanation, Mark. Wolfgang Westphal -----Original Message----- From: Mark Miesfeld [mailto:mie...@gm...] Sent: Wednesday, December 19, 2012 3:36 PM To: Open Object Rexx Users Subject: Re: [Oorexx-users] SYSFILETREE doesn't return the correct size of large files On Wed, Dec 19, 2012 at 3:37 AM, Wolfgang Westphal <wol...@we...> wrote: > It looks like the size of files with more than 4294967295 bytes isn't > returned correctly by Rexx Utility SYSFILETREE. That's correct. Due to backwards compatibility restraints, the size of the field can not be extended. The File class supports greater than 4 GB file sizes. -- Mark Miesfeld ---------------------------------------------------------------------------- -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ Oorexx-users mailing list Oor...@li... https://lists.sourceforge.net/lists/listinfo/oorexx-users |
From: Robert H. <bob...@gm...> - 2012-12-20 20:42:00
|
Test Bob Hamilton On Wed, Dec 19, 2012 at 10:02 PM, Wolfgang Westphal <wol...@we...> wrote: > Thank you for your explanation, Mark. > > Wolfgang Westphal > > -----Original Message----- > From: Mark Miesfeld [mailto:mie...@gm...] > Sent: Wednesday, December 19, 2012 3:36 PM > To: Open Object Rexx Users > Subject: Re: [Oorexx-users] SYSFILETREE doesn't return the correct size of > large files > > On Wed, Dec 19, 2012 at 3:37 AM, Wolfgang Westphal > <wol...@we...> wrote: > >> It looks like the size of files with more than 4294967295 bytes isn't >> returned correctly by Rexx Utility SYSFILETREE. > > That's correct. Due to backwards compatibility restraints, the size > of the field can not be extended. The File class supports greater > than 4 GB file sizes. > > -- > Mark Miesfeld > > ---------------------------------------------------------------------------- > -- > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > Oorexx-users mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-users > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > Oorexx-users mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-users |