Mon 17 Jul 2017 09:20:37 PM UTC, comment #13:
Sure, but does the builtin methods.m (in scripts/general/) still work for for classdef & Java objects then? I suppose it'll get shadowed.
Since your fix in comment #4, methods.m in core now does at least something for COM objects.
Looking in scripts/general/methods.m, for "general" objects _methods_ is called (in ov-class.cc) that doesn't know about COM objects:
which are general COM methods (optionally with "com_" prefixed) while the real list is shown (partly) in comment #9.
So I think when the windows package gets loaded it is _methods_() that needs to be overloaded (as we can't add COM-specific stuff to core Octave).
That's as far as my probably oversimplified OOP reasoning goes :-)
|
Mon 17 Jul 2017 08:29:41 PM UTC, comment #9:
something like:
I'm not so familiar with OOP; but anyway, what I think is that as methods(app) doesn't work, maybe _COM_.cc can contain a function that overloads or supplements the core Octave methods() function to also work on COM objects?
|
Mon 17 Jul 2017 06:37:31 PM UTC, comment #6:
Thanks, works fine here.
Will you push the fix to the of-windows repo?
BTW I saw that there's no "methods" call for COM objects, yet
com_invoke (<COM-object>)
w/o specifying a method will return a list of methods for that object. Would it be difficult to use this info for making an overloading "methods" function for COM objects?
|
Mon 17 Jul 2017 03:09:35 PM UTC, comment #2:
It is possible to work around it using the com_invoke, com_get and com_set functions (much like bug #511532 could be worked around using javaMethod), but that's quite clumsy and does not make for easy to maintain code.
Mike's fix for bug #51152 merely comprised addition of a "isjava(<obj>)" call to an if clause in pt-eval.cc. However that is relatively easy as isjava() is built into core Octave, while an "iscom()" call would have to come from an add-on package.
Maybe COM objects can be masqueraded as general objects?
|
Sat 15 Jul 2017 10:09:25 AM UTC, original submission:
I'm a little afraid this is another manifestation of bug #51152
COM objects (ActiveX objects) do not accept arguments, sometimes not even parentheses enclosing the argument(s).
I hit this when investigating io package problems while invoking Excel through ActiveX. If needed I can show how to reproduce the bug with LibreOffice, but then I'd need to search & undig some old scripts. But the bug can simply be demonstrated with Notepad.exe as well.
Steps to reproduce:
- install and load windows package
- then:
Expected result (here with Octave-3.9.0+ I still had installed):
(the latter hidden behind a full-screen Notepad window. Just use Alt-tab to get to the Octave terminal)
To close the app object, do File | Exit in Notepad and in Octave just:
delete (app);
|