52

I can fire up Excel with the following script. But in ghci (7.4.1) I have a segmentation fault when I run it.

I don't know where to search from now. I don't have this error if I remove the line 

workSheets <- workBook #  propertyGet_0 "Worksheets"

Here is the code. May be I forgot something. I read the source code of com.hs here, but it doesn't give me any clue. 

import System.Win32.Com 
import System.Win32.Com.Automation
--
-- createObjectExcel 
-- coming from Automation.hs and com.hs
--

iidIDispatch_unsafe  = mkIID "{00020400-0000-0000-C000-000000000046}"

createObjExl :: IO (IDispatch ()) 
createObjExl = do
    clsidExcel <- clsidFromProgID "Excel.Application"
    pExl <- coCreateInstance clsidExcel  Nothing LocalProcess iidIDispatch_unsafe
    return pExl


fichierTest2 = "E:/Programmation/haskell/Com/qos1.xls"

main = coRun $ do 
    pExl <- createObjExl
    workBooks <- pExl #  propertyGet_0 "Workbooks"
    workBook <- workBooks #  propertyGet_1 "Open" fichierTest2
    workSheets <- workBook #  propertyGet_0 "Worksheets"

    workBooks # method_1_0 "Close" (0::Int)
    pExl # method_0_0 "Quit"

    mapM release [workSheets,workBook, workBooks, pExl]

Edit with Gonzalez's advice I tried debugging, but no information arose. I tried the code by hand in ghci, and it seemed that the guilty party was the release function.

When I entered these in ghci, I got the segmentation fault: 

*Main> coInitialize
*Main> pExl <- createObjExl
*Main> release pExl
0

Now if I hit "pExl" I have a reference. Shouldn't that be set to Null? 

*Main> pExl
<interface pointer = 0x020844cc>

*Main> coUnInitialize
*Main> :q
leaving Ghci
Segmentation Fault/access violation ...
pcurry
  • 1,374
  • 11
  • 23
jinkou2 jinkou2
  • 1,096
  • 7
  • 13
  • 3
    A cursory glance at the code indicates that the guilty function might be `primInvokeMethod` which does all the raw memory operations. You can use `ghci`'s [debugging facilities](http://www.haskell.org/ghc/docs/latest/html/users_guide/ghci-debugger.html) to narrow down where in the source the segmentation fault triggers and what parameters cause it to fail. I don't have a windows machine, so I can't test it myself. – Gabriella Gonzalez Jan 26 '13 at 17:46
  • 1
    Can you try in GHC (i.e. compiled)? – Don Stewart Feb 24 '13 at 12:54
  • 1
    It effectively works with GHC. And also there is no need to release like "mapM release [workSheets,workBook, workBooks, pExl]" since it is garbage collected. there was also a pb in the mkiid. I will post a fully working example in reddit. – jinkou2 jinkou2 Feb 27 '13 at 20:54
  • Have you actually tested, before calling the Worksheets method, that workBook is not null? That seems the most obvious thing to test, since if that were null, I imagine you'd get exactly the behaviour you're seeing. – Gary McGill Sep 06 '13 at 10:29
  • PS. The WorkbookS.Close method takes no parameters, yet you seem to be passing something in. I would normally use Workbook.Close, which does take parameters. – Gary McGill Sep 06 '13 at 10:30
  • 1
    The main reason is that ghci is multithreaded, and com package calls OleInitialize. OleInitializes specifies single threaded COM model. I believe that this is the main reason for failure. Compiled package with single threaded flag should work correctly. – Yogesh Sajanikar Jan 22 '14 at 08:36

1 Answers1

1

You might be calling the workSheets method from within a static function. Try moving it out.

Or, have you tried explicitly declaring the data type of 'Worksheets'

WorkSheets :: Int -> Int or (whatever type is should be).

Fyor Nikowski
  • 1
  • 3