#1227 Private methods not found in userdialog subclass

None
wont-fix
ooDialog (58)
none
1
2013-12-29
2013-12-23
Jon Wolfers
No

This is a change of behaviour between 4.1.0 and 4.2.3
Rexx:REXX-ooRexx_4.1.1(MT) 4.1.1
6.03 16 May 2012
ooDialog:4.2.3.9748 (an ooRexx Windows Extension)
Windows 7 pro 32bit

If a userdialog subclass has a method defined with sub-keyword private then it cannot call it in 4.2.3 whereas it can in a previous version

I receive the message 'xxxxx is not a method of an yyyyy'

Removing the 'PRIVATE' sub-keyword from the xxxxx method directive resolves this, as does falling back to previous version of ooDialog.

I attach a simple test case script - pressing the private button should show 'Private method running'

I have not tested intermediate versions of ooDialog, so this behaviour may have been introduced at an earlier stage.

thanks
Jon

1 Attachments

Discussion

  • Mark Miesfeld

    Mark Miesfeld - 2013-12-23
    • labels: --> ooDialog
     
  • Mark Miesfeld

    Mark Miesfeld - 2013-12-23

    Jon,

    Event handling methods have to be public. The methods are invoked from the window processing loop by invoking the method on the dialog object. You can not invoke a private method.

    This would not work either:

    / private methods not seen /
    dlg=.testDlg~new
    dlg~executeAsync
    dlg~onPrivate
    dlg~endAsyncExecution

    I had never seen any one code an event handler as private and it would never occur to me that anyone would. So, I have to admit I never really thought about this before in relation to moving from what I think of as the old ooDialog and the modern ooDialog.

    If you think about what the dynamics are here, the operating system has to send messages to the dialog. The abstraction is, objectA needs to send a message to objectB. Object Cat needs to send a message to object Owner by invoking a method on object Owner. The method has to be public.

    I'm afraid this will be a permanent restriction.

    If for whatever reason you need to keep methods private, you will need to have a public event handler and connect that event handler to your events. Then use that public method in your dialog to dispatch the events to your private methods.

     
  • Mark Miesfeld

    Mark Miesfeld - 2013-12-23
    • status: open --> wont-fix
    • assigned_to: Mark Miesfeld
    • Group: ooDialog.4.2.3 --> None
     
  • Jon Wolfers

    Jon Wolfers - 2013-12-23

    Hi Mark,

    OK.

    Just for the record, I also would not have expected an event handler set as private to work when called from a method outside it's own class as you demonstrate - that is exactly what I understand the private keyword to do.

    I hope I can express this next bit clearly:
    On the other hand, it seems to me to be reasonable to assume that the correct usage outside the sphere of ooDialog is that where you have a method that is intended only to receive messages from it's own class you mark it as private. And I have done that in a few places - only in the interest of correctness. I can't imagine that taking the private keywords off will make any detrimental difference at all to the functionality of my code.

    However, this is a change in behaviour and it does break my code in several rather obscure ways. And as the behaviour worked previously for many years it may well be worth documenting this added restriction - however unreasonable you think my use of the sub-keyword was.

    thanks for your hard work.

    Jon

     
  • Mark Miesfeld

    Mark Miesfeld - 2013-12-29

    Committed revision 9768. [r9768]

    Updated the documentation on how to code event handlers to emphasis event handlers must be public.

     

    Related

    Commit: [r9768]


Anonymous

Cancel  Add attachments





Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks