Sat 02 May 2015 12:38:25 PM UTC, comment #11:
See bug #44998 where the remaining issue (of miscompiled _COM_.oct for 64-bit Octave) is reported.
With the temporary workaround there, the Windows package works as expected.
Closing report
|
Wed 15 Apr 2015 11:31:03 PM UTC, comment #10:
Patch for all added to mxe-octave http://hg.octave.org/mxe-octave/shortlog/02a0022a6f75
(file #33684)
|
Wed 15 Apr 2015 05:31:21 PM UTC, comment #9:
This patch stops the error mentioned in comment 5.
I have another patch for cross compiling it in mxe-octave - it also makes grab compile as well - I will throw up a combined patch later today
(file #33681)
|
Sat 21 Mar 2015 12:05:35 PM UTC, comment #8:
I think a test should be added to avoid installing on 64-bit Octave. If it gets installed there it'll crash Octave hard, w/o any clue for users what happened => bad for Octave's reputation
During installation, the windows pkg calls octave_config_info so 32/64 bit could easily be established; but as Mike recently found out, this specific (outdated) pkg installation stuff leads to other issues.
I hope the maintainer (Michael Goffioul) can find the time to fix the windows package issues.
|
Sun 15 Mar 2015 09:37:51 PM UTC, comment #7:
Attached windows-1.2.2.tar.gz, build according to comment #1.
Of course, there are still the problems of 64-bit, described in
comments #3-#6
(file #33355)
|
Sat 14 Mar 2015 11:24:08 PM UTC, comment #6:
Yes I saw that too.
But with a 32-bit Octave-4.0.0-rc1 the command does return a valid COM object:just try
app.Quit()
it should return something like []0x0
(After that issue "delete (app)" to end the silent Excel.exe running behind the scenes, look in Task Manager processes tab)
|
Fri 13 Mar 2015 07:15:27 PM UTC, comment #5:
making the changes from your comment 1 allows me to compile ok, however on running on my Win7 machine (32 bit octave installed):
|
Fri 13 Mar 2015 05:52:28 PM UTC, comment #4:
With 32-bit Octave (like on ftp.gnu.org) the windows package as fixed along comment #1 still works in spite of the error message; a valid COM object is returned.
With Octave built for 64-bit Windows, the amended windows package crashes Octave hard, however:
app = actxserver ("Excel.Application")
## error message but some COM object returned
app.Quit()
.....=> crash
so it seems the windows package is miscompiled for 64-bit systems.
|
Fri 27 Feb 2015 10:03:26 AM UTC, comment #3:
With a recent build of Octave-3.9.1+ (w. 64-bit indexing) I now see that the COM interface doesn't work anymore, where it still did work a week ago.
Commands like "actxserver ("Excel.Application") do return a COM object but one that contains only a COM error message; i.o.w. the link to the activeX server became disfunctional.
|
Fri 20 Feb 2015 02:39:05 PM UTC, comment #2:
Looking in the grab() docs, I see that its functionality more or less mimics that of ginput().
Another motive to drop it from the Windows package?
|
Sun 15 Feb 2015 09:29:43 PM UTC, comment #1:
I could get windows-1.2.1 to build again by:
- Commenting out the grab.oct stuff in Makefile.
grab() is rarely used AFAICS; it isn't available on non-Windows systems anyway so I think a case can be made to drop it completely.
- Removing lines 192 and 183 (DEFINE_OCTAVE_ALLOCATOR and DECLARE_OCTAVE_ALLOCATOR) in _COM_.cc (these deprecated macros have been removed 3 weeks ago from core Octave).
With those changes the spreadsheet I/O works fine with the COM/ActiveX interface (quite a good test for that IMO).
As to grab.cc, I can't assess what has changed in Octave's core code. Until a few weeks ago the windows pkg would build w/o problems with the (then) default branch.
I'll cc Michael Goffioul (windows pkg maintainer)
|
Tue 03 Feb 2015 07:32:59 PM UTC, original submission:
|