I'm writing programs in C\C++ embedding Excel and handling it's COM object.
This automation process works flawlessly to manipulate sheets and getting benefit of excel capabilities.
M problem is that while processing data i use copy/paste operations, so if the processing takes some time, it's possible that interference happens as the clipboard is common between running processes
i don't know if there's a way privatize the clipboard or any other idea to avoid such problem
Thanks in advance
You cannot make a private clipboard and expect it to work with normal cut/copy/paste operations. You can use delays to avoid clipboard clashes. i.e. after you force a copy operation, wait a few hundred ms before pasting.
Also, programmatic use of the clipboard is considered bad practice. The clipboard is provided for the convenience of the user, not the programmer. See my favorite quote on the subject:
“Programs should not transfer data into our out of the clipboard
without an explicit instruction from the user.” — Charles Petzold,
Programming Windows 3.1, Microsoft Press, 1992
I found a way to do it for PowerShell scripts:
Create a Scheduled Task that call your script/program
Set it to "Run whether user is logged on or not"
When you run the Scheduled Task, Windows launch the script/program in a background session that uses its own Clipboard, not interfering with the one of the active session you have.
Related
I have two processes that operate on a single Excel file.
The first process creates the Excel instance and opens/creates and activates a workbook and worksheet. The second process makes entries to the spreadsheet. The first process passes the Excel handle as an output parameter to the second process but, when the second process attempts to interact with the workbook, a "Given key not in dictionary" error occurs.
I speculate that the handle is just a means for a process to distinguish between Excel instances to which it is connected and the second process needs to connect to the Excel instance opened by the first process. The Excel VBO contains Attach and Attach Worksheet pages that may provide this functionality, but I cannot find any instructions or documentation for the Excel VBO. There may be more than one Excel instance open and I'm not sure how to refer to the correct instance.
Is my assumption that I need to connect the second process to the Excel instance opened by the first process correct? If so, how do I do this? If not, can anyone tell me what causes the dictionary error and how I can address it?
handles are kept track of internally in memory by a particular instance of the MS Excel VBO. They are not shared between instances of the VBO.
Given the above, and assuming your code is set up exactly as you've described (two distinct processes), this is expected behavior: the instance of the MS Excel VBO that holds the handle for the instance of Excel you're attempting to interact with is purged from memory at the end of the process.
Regarding the "Attach" functionality and associated documentation: most all out-of-the-box VBOs do have documentation available, and is always accessible by clicking the "i" button as emphasized in my screenshot below:
Clicking this pops an Internet Explorer window with the documentation for the particular object you have set in the "Business Object" field of this window. In this case, the MS Excel VBO action "Attach" has the following description:
1.3 Attach
Back-compatible link to 'Open Instance'. This opens the first running
instance of Excel found and links to it in this object. Returns:
- handle : Number : An integer with which the instance opened can be
identified.
- Enable Events : Flag : Indicates that events should be
enabled / disabled on the attached instance - defaulted to True
In your particular use case, this may be a viable action. In most cases/designs (esp. including considerations for resiliency), it should be considered that the automated solution may inadvertently attach to another Excel instance (if one is present). As such, you might want to consider re-factoring your process design to create and interact with the Excel instance within the same Blue Prism process. If you need logical separation of the code that launches Excel & handles the processing, you might consider using individual Pages and page references as opposed to separate processes altogether.
The last point above lends nicely to your assumption regarding the use of handle. At the risk of being redundant: your assumption itself is correct, but you might want to consider a slight re-design to your processes. It's unlikely that the optimal design of a given Blue Prism process would open an instance of Excel in one process, and not interact with it until another process.
Is it possible two add delay time between execution of commands while using macros, it's like doing the macro in a slow motion... something like macro_dala = 200ms ...if this is not possible, what about adding a delay command while recording..
It depends from content of macro but in general you cannot achieve that unless you create a tool for us that can parse successfully all vim commands (and why not including mappings, plugins and ... :) just think about it for a while).
In case you insist and want to use it for SIMPLE & KNOWN commands, you can make it work by programming a function that will read the register where you hold your macro and then separate each command. After that, make a delay after each execution.
I'm using windows 8. Recently the task manager has been basically not working. It freezes and is just generally terrible.
What's more, as apposed to the earlier version of windows, the task-manager thread seems to not have the same priority that it once did. When I hit Ctr+Alt+Delete, the system immediately calls the home screen, but when I open task manager, I get lag.
What I want to do is create my own hotkey sequence to interrupt all systems with as much priority as possible. The notion here is an overclocking mentality, where if the hardware fails, that is more acceptable to me than a lag-lock lasting 5 minutes.
The idea of creating a custom hotkey seems realistically overly complicated. I recently began using 'resmon', and it is fantastic. If there was a way to launch resmon directly from the home screen, with high level priority, that would be an acceptable solution.
It sounds like you want to look at Windows Hook Functions, which allow you to run your own code at various points between the time when a keyboard event is received and when applications receive it.
Additionally, if you don't want to write code, you can attempt to do the following two steps. This is untested because I do not currently have a windows box handy.
Play with Image File Execution Options in the Windows Registry so that resmon will always get executed instead of the Task Manager, by setting it as the debugger for Task Manager in the following key.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\taskmgr.exe
Instead of using Ctrl-Alt-Delete, use the key sequence Ctrl-Shift-Esc which should attempt to bring up the task manager.
I built a package in SSIS that uses a script task to open an Excel file, format, and refresh some data in Excel. I would like to have Excel visible when the script task is running to see if Excel gets hung up which occurs all the time. Is this possible? I am converting a process that is calling Excel via a shell script to using SSIS to call Excel instead. I guess a second question is, is that a bad idea?
Why this is a bad idea
Generally speaking, administrators are tasked with maximizing the amount of "uptime" a server or service on the server has. The more software that gets installed on the machine, the greater the odds of service interruptions and outages due to patching. To be able to manipulate Excel in the mechanism you described, you're going to force the installation of MS Office on that machine. That will cost you a software license and the amount of patching required is going to blow holes in whatever SLAs those admins might be required to adhere to.
Memory leaks. Along with the whole patching bit, in the past at least, there were issues with programmatically manipulating Excel and it basically boiled down to it was easy to end up with memory leaks (I gotta make you understand. Allocated memory but never given it up, never let the allocated memory go down). Over time, the compounded effect is that running this package will result in less and less system memory available and the only way to reclaim it is through a reboot, which gets back to SLAs.
The reason you want to see what Excel is doing is so that you can monitor execution because it "gets hung up which occurs all the time". That doesn't sound like a stable process. Again, no admin is going to want an unstable process running on the servers. Something is not right in the cycle of events. Whether it's your code that opens Excel, the macros it runs, etc, something in there is awry and that's why you need to inspect the process. This is akin to putting a bandaid on a shotgun wound. Stop shooting yourself and you won't require bandages.
The task that you're attempting to perform is "open an Excel file, format, and refresh some data in Excel" SSIS can natively push data into Excel. If you preformat the file, develop your SSIS to write to the formatted file and just copy it off, that should work. It's not graceful but it works. There are better methods of providing formatted data but without knowing your infrastructure, I don't know if SSRS, SharePoint, Excel Services, Power Pivot, etc are viable options.
Why you won't be able to see Excel
Generally speaking, the account that runs SQL Agent is probably going to be fairly powerful. To prevent things like a shatter attack, from Windows 2008+ services are restricted in what they can do. For the service account to be able to interact with the desktop, you have to move it into the user tier of apps which might not be a good thing if you, or your DBA/admins, are risk adverse.
For more information, please to enjoy the following links
InteractWithDesktop
http://lostechies.com/keithdahlby/2011/08/13/allowing-a-windows-service-to-interact-with-desktop-without-localsystem/
https://serverfault.com/questions/576144/allow-service-to-interact-with-desktop
https://superuser.com/questions/415204/how-do-i-allow-interactive-services-in-windows-7
That said, if all of the stars are aligned and you accept the risk, of Allow Service to Interact with the Desktop, the answer is exactly as Sam indicated. In your unshown code, you need to set the Visible property to true.
As you go off and allow interactivity with the desktop and someone leaves some "testing" code in the package that gets deployed to production with MessageBox.Show("Click OK to continue"); be aware that if nobody notices this dialog box sitting there, you'll have a job waiting to complete for a very long time.
Regarding your first question, I understand that you want to debug your script task.
You can make Excel visible by adding the following line of code in your script task (assuming C# is the coding language):
// Create your Excel app
var excelApp = new Excel.Application();
// Make the Excel window visible to spot any issues
excelApp.Visible = true;
Don't forget to remove/comment that line after debugging.
Regarding your second question, I don't that this is a bad idea if you properly handle how Excel is opened and closed, in order to avoid memory issues.
I'd like to be able to schedule an Excel macro (VBA) to run in the middle of the night (after a file is ready) to create a customized workbook (multiple sheets, pivot tables, charts, filters, outlines, custom formatting, etc.). Currently, the macro is fired up manually the next day. Furthermore, it needs to run unattended on a server (laptop goes home at night!). Anybody successfully do something like this? Please, no Unix-side hacks (e.g., Perl modules) - need full access to VBA features, including database functions. Thanks!
Well you have some options.
First, for all Excel has to be installed on server.
Then you create a sheduled task to call a program.
In this case you can write e.g. a vbscript or .NET program to call the app, load the document and starts its content (your VBA). That should work at all.
Or you move the VBA code to a program and target Excel with your code, but prolly more work.
If you do this with .NET you have prolly best success. e.g. you can add an eventlog for successful run, etc.
If you can leave Excel running on the server all the time, you can use Application.OnTime to schedule the next runs of a particular macro (once it's run, reschedule another in the macro code). When I worked in banking we used this all the time to run night-time jobs.
If you cannot leave Excel running, I have to say you may be in a world of pain. It's possible to start Excel using an AT job (scheduled task) but you may have headaches getting it to run under the correct user privileges and if you use any addins you'll experience regular disasters where they failed to load and stopped Excel from starting up. At the end of the day, Excel isn't really meant to be run on servers (it's actually a violation of the terms of use) and starting/running/stopping it is not going to be a reliable system even if you do get it to work.