Bagel

I see, so when we declare the two variables $oWorkbook and $sWorkbook one is the object name that we will use to refer to the workbook that we're attaching to and the other is simply a string that we're telling _Excel_BookAttach to search for when looking for the already open Excel book. And, confirmed, I can in fact use _Excel_BookAttach to manipulate the spreadsheet without calling _Excel_Open(). I think what was confusing me is that when I read about the UDF the wiki states at one point that all of the following functions must be preceded by _Excel_Open() and then every example I saw in the documentation after that point used _Excel_Open() AND _Excel_BookOpen. Which then lead me down a dark rabbit hole and left me wondering... why would we need to open Excel if it's already open and we're just trying interface with it, what's the point of using _Excel_BookAttach if we have to run Excel (again) and open the book directly beforehand... I'm now able to do everything that I needed to in order to move forward with my project. Thanks again!

Okay, thanks a lot for the clarification. I will investigate more when I have the time. And, water, I'll review your post again.

What I've tried is this: #include <Array.au3> #include <Excel.au3> ;~ Create or connect to existing Excel instance Local $oExcel = _Excel_Open() ;~ Workbook variables Local $oWorkbook, $sWorkbook = "Book8.xlsx" ;Local $oWorkbook = _Excel_BookOpen($oExcel, @ScriptDir & "\Book8.xlsx", Default, Default) ;~ Try attach to workbook $oWorkbook = _Excel_BookAttach($sWorkbook, "Book8") Local $aArray[3] = ['A', 'B', 'C'] _ArrayTranspose($aArray) _Excel_RangeWrite($oWorkbook, $oWorkbook.ActiveSheet, $aArray, 'A1', Default, Default) If @error = 1 Then ;~ If open workbook wasn't found, open the workbook $oWorkbook = _Excel_BookOpen($oExcel, $sWorkbook) If @error Then Exit MsgBox(48, "Workbook Error", $sWorkbook & " - Workbook not found") EndIf This fails, but it works if I uncomment the line opening the book. But why is it necessary to keep reopening the book? If Autoit can search for and grab the window by the title shouldn't there be some way to grab the already open window as an object and then work with it using the Excel functions? What I have in my use case is multiple scripts that need to be able to interact with a single open workbook. I guess I could try code that automatically opens the workbook, makes the necessary changes, then saves and closes the workbook before another script needs to use it. But then I have to worry about conflicts where multiple scripts are trying to open/save/close the same workbook simultaneously. If simply opening the workbook activates a sheet and leaves it ready to be written to, then why would we need a separate "_Excel_BookAttach" function in the first place? What is it's purpose if not, as the name suggests to me, to allow us, in code, to grab an already open workbook and manipulate it without re-opening it or another book?

I have a need to allow multiple separate scripts to have access to an Excel spreadsheet that is already open. I'm not quite sure how to do this. From what I understand of the Excel UDF _Excel_Open() will need to be called in each of the scripts. Now comes _Excel_BookAttach. Which I think will allow the workbook objects I create in each of the scripts to grab the single open workbook and interact with it, although I'm not sure about this. So anyway, my question is, does the BookAttach function work this way? From what I understand, if an instance of Excel is already running when I call _Excel_Open() then the handle will reference the already created instance. But every example of using the BookAttach function shows that a workbook must first be opened with _Excel_BookOpen (I guess in my case it would have to be the workbook that's ALREADY opened). Will this need to be repeated for each script that wants to use the spreadsheet? I've searched around and can't find any clarity on this. Basically, I have no idea what BookAttach is actually doing how it should be useful.

Also, many of the "child" scripts often have to receive information from the GUI. Like when particular buttons and controls are used. What I've done to achieve this is create Do loops that continuously check the status of those controls to detect a user change using ControlGetText.

Yes, I've implemented largely your example. I just kept the code dealing with the requests in an IF statement and then moved the IF statement below the Switch I'm using. I'll get to employ and test all the new code in a live environment tomorrow. The tool seems particularly well suited for my use case. I have, at times, multiple scripts running which need to communicate with a GUI I have created to manage them. What I've done in many cases to transfer data between them, when necessary, is create a control on the GUI and have one of the other scripts store information in the control so that the GUI can access it. But that is an ugly kludge I've had to resort to. I really had no idea it was possible to transfer data between processes like this. I wish it were possible to use with all the 3rd party applications I have to interface with. One thing I'm curious about, what would your opinion be of the performance of transferring information via your WCD-IPC vs. using something like ControlSetText and then having the GUI read from that control? Or having to use ControlSetText to populate a group of controls with information and having WCD-IPC send all the data via a single send and then having the GUI populate the controls? I've never tested performance of something so complicated. Do you have any advice on how to set up such a test?

Okay, I figured it out. The Switch is using "$nMsg" as the expressions since it's in a GUI and most of the time it's returning "0" and when it does, it matches what _WCD_Server_IsRequestAvail() is returning since there aren't any requests available and hence executes the code inside the case. Now I just need to figure out how to rework the code around this. Incidentally, I've been wondering, is there a shelf life to the requests that are queued up and haven't been received? Will they die after a time or reside on the server indefinitely?

I just had some ideas on how to test a bit further and I think you're right. There is something wrong with how I'm using the Switch/Case statement but I can't tell what it is. When I use _WCD_Server_IsRequestAvail() in ConsoleWrite it produces False as expected since I don't have a client running that has sent any requests. So none of the code inside the Case should be executing. I need to investigate a bit more.

Nine, I am using _WCD_Server_IsRequestAvail() as a Case in a Switch. Offhand, do you know why Case _WCD_Server_IsRequestAvail() ~code would crash the script silently and Case _WCD_Server_IsRequestAvail() If _WCD_Server_IsRequestAvail() Then ~code EndIf would NOT cause a crash? In both situations there isn't even a client running let alone a request being sent. My intention is of course to execute the Case code only when a client sends data but I'm concerned that something else is going on and don't want to add any overhead to the script if possible. Thanks

Yep, apparently I have some sort of subconscious issue that's crossing my wires when the "$" is involved. Not sure the forums can help me with that. Actually, I think this time it was a conceptual issue regarding variables. It's ingrained in me that variables MUST begin with a "$" and I think that led me to make an implicit assumption about what Eval() was doing. Conceptually, Eval() and Assign() etc. are a bit abstract to me. Thanks again for the help!

And kicking myself. In fleshing out some of my code I just made ANOTHER error in omitting an "$" where there should have been one. At least I was the one who caught it this time.

Oh I see what I did. Thanks!

Not completely but I'm trying to figure out how to use it my scenario. Eval is still failing silently and I'm looking at Assign().

Oh my god.

Oh it's you again! Now that's not fair, I included the "$" this time! Now what am I ACTUALLY missing?