I created a protocol generation tool that reads some data from a websource, allows the user to filter some of the fields an generate a protocol based on given filterdata. The protocol is generated as a word document that is edited multiple times, on multiple layers, before shown to the user.
For some users the line:
Process.Start(pathtowordfile)
does not open Word, for others it works fine.
Even more strange: if the useres try to generate the protocol the first time it opens. if they change one of the filters and generate again, the file does not open. But it is generated correctly, you are able to open it manually.
We are using Windows 7 on all machines and, in general, the User has no administrativ privileges on the machine.
Are there any alternatives to
Process.Start()
?
Not sure how the code can sometimes work, but the critical bit I think would be to make sure you set UseShellExecute=true when you are trying to Process.Start a file that is not an executable.
https://msdn.microsoft.com/en-us/library/system.diagnostics.processstartinfo.useshellexecute%28v=vs.110%29.aspx
I haven't looked into it in quite awhile, but last I checked shell execute relies on the Word application to be properly registered with DDE so Windows knows what to do with a .doc(x) file. Word may not be installed "properly".
after trying varios things, including Wonko's hint, I dicided to use the interop.Word.Wordapplication to display the document. It doesn't explain why process.start not does the job but anyway, now everybody of the users is happy^^
Related
I have a single command line windows executable that has many options built into this exe file.
Eg:
(It can take screenshot)
ToolGo.exe printscreen c:\temp\filename.jpg yyyymmdd
(It can show up)
ToolGo.exe showIP machineA
I want to write another command line application, possibly in .net , where it can embed/build a wrapper around this ToolGo.exe file into my application without the user be able to use the ToolGo.exe, and also users can only access one function of this main exe file.
In the example I want this other tool to access only the print screen function in this new exe file.
The new application will have this:
Tool2go.exe printscreen c:\temp\filename.jpg yyyymmdd
But if someone types the following, it will not work:
Tool2go.exe showIP machineA
Or
ToolGo.exe showIP machineA
Any ideas how I can write this code to do this in a .net command line application?
This is a multi-part question, so I'll just give the main part of the issue as the answer with suggestions on handling the rest.
You can embed a .exe into your program by clicking on Properties and navigating the the Resources section, and adding that .exe to it.
After that, it's just a matter of extracting it locally so you can pass your commands to it, and handle it's responses. (I'm not really aware of any way to do so w/out first extracting the. exe; the .exe itself needs to run somehow after all).
To extract the embedded .exe, you do this:
' Extract the MyProgram resource (i.e. your .exe)
Dim b() As Byte = My.Resources.MyProgram
' Write it to the user's Temp folder
File.WriteAllBytes(Environment.ExpandEnvironmentVariables("%TEMP%\MyProgram.exe"), b)
By extracting it to the user's Temp folder, you can pass it your commands, and since it's 'out of sight' the user probably won't even know it's there to directly use it themselves, unless they're a bit more advanced and visit their Temp folder often. You can slightly help to avoid this, but extracting the .exe when your program starts, and then deleting it when it exits, so it only exists on the user's system while your program is running.
As far as what the user can and cannot type in order to pass to the program, you can simply handle the filtering with your program; since your program is the one passing the commands to the .exe, just don't pass any commands that you don't allowed, and pass the ones you do want allowed.
I came by this page and was thinking about the best method to distribute my VbaProject.OTM file (located into %appdata%\Microsoft\Outlook\) to a bunch of ~30 users at my office. Is it better to simply copy/paste the OTM file onto the network and then copy/paste it back to all users' computers (manually or with a .bat) OR would it be better to use the method described in the link above to generate a OPS file and import it back with Proflwiz.exe? What's the difference?
We are all on Microsoft Office Outlook 2003 actually, we might upgrade to 2007 one day but still years from now.
Finally came up with some elements to deploy a Outlook VBA Project. There are a lot of ways to do this, but the easiest way to do so without installing anything and keeping the same methodology would be to run a OTM file directly from a server. I found out that the process outlook.exe has a parameter altvba that allows to specify another path to run the OTM file from. Here is en example:
outlook.exe /altvba "\\myServer\myFolder\myFile.otm"
This allows me to update only one file to get all computers updated. Obviously, if the file is big and the server's ping is on the high side, it may delay the launch of Outlook. The other problem with this method is that everybody will have to shut down Office if you want to update the OTM file on the server (and if you do work in an office where everyone uses Outlook, you do know that it is impossible to get everyone to shut it down at the same time, except if you code a macro to do so eventually). To prevent both those problems, I could setup a batch file to copy the server OTM file clientside everytime there is a new version (just have to check the NTFS last-modify attribute). This way, Outlook will boot with a local file, the batch file take 2-3 seconds to copy the file if needed (or will launch Outlook instantaneously) and there will be no problem updating the OTM file on the server. Users will have to start Outlook with the batch file (or with the slightly different outlook.exe path with the altvba parameter, so either way they need a different shortcut/file to start off the first time). One other advantage of the altvba is that it's still easy for the user to run Outlook without it (to see if the VBA is problematic or not in case Outlook is sluggish) and the file will remain unchanged after a Outlook reinitialization.
Others solutions include a COM complement that can be developed in a lot on languages including VB6 (no conversion needed from VBA). There is also a bunch of tools included into Microsoft Office XP Developer that could help getting the job done (not free however, especially if you need the most up-to-date version).
We have a process at our company that processes TIFF images. I have a project where I want to be able to capture emails that people have received and let them pass it on to our imaging process. Right now forwarding an email isn't really an option but our initial thought was that we could create an Outlook addin that would create and send an image of the email to our internal webservice and it would just work.
I'm developing on Windows 7 with VS2010 and Outlook 2007.
I have the basic addin framework setup - that seems to work OK. The addin is there, popping a regular Windows form where I can do my stuff. But now I'm running into problems. First I was going leverage the built-in Microsoft Office Document Image Writer which can write to TIFFs. However, this doesn't appear to be installed as part of Office 2007 on Windows 7. Then I found some references that it didn't work on Win7 64bit in the first place, and that Microsoft was phasing it out in favor of their XPS printer anyway.
Then I moved on to thinking I could maybe use PDFCreator. This sort of works, except it looks like I have to actually have PDFCreator installed on the client machine, too. I was really hoping I could just bundle the dll and PDFCreator could natively "print", but it seems rely on you setting the active printer to "PDFCreator" and still printing to that. I was already maybe going to run into problems pushing a custom addin out to users in the first place; I don't know if I could get a new printer rolled out as a requirement, too.
On top of that, you apparently can't set the active/default printer in Outlook once it's running. So my plan to run the addin, change the default printer to PDFCreator, print it, then change it back isn't going to work after all anyway.
We really wanted to be able to capture emails as if the user had printed them out and scanned them, which is what they have to do now. I would really not like to rely on copying/pasting into another application if I can help with it.
Sooooooo, what other options might I have? Is there any close to native functionality in Windows or Office that would let me print to something and eventually get a TIFF? Does it look like I'm going to have to try and string together a bunch of 3rd party tools or something? It looks like the only way to "print" an email is to do the MailItem.PrintOut() command, which is just going to go to whatever the current default printer is. Are there any other TIFF-printing things available that wouldn't involve installing a new virtual printer on the end user's machine? Any other ideas? Thanks for any help!
Although you ruled it out at the start of the question...
Assuming you need those tiffs at a central location and not at the employee desktop.... I'd still advise you to have your addin forward the respective mail to a central location (as an attachment to a automated mail, or perhaps just write it to a queue folder on some network location), then have a central process pick it up and print it out to tiff files.
Unless you have exact control over the client machines at your company (which from the sound of it, you don't), you really want to move some fickle as 'switching printers in Outlook' away from the clients.
That doesn't mean this approach doesn't require hacks as well, because that central process will be running outlook to do the work.
I assume it is important that your tiffs look like they were actually printed from Outlook, if not please add that as extra information to your question, as it opens new routes. Like capturing the email-screen rendering and putting that inside a tiff file, which can all be done on any desktop machine.
I have a small VB .Net application that, among other things, attempts to substitute system wide typed text by the user(hotstrings concept). To achieve that, I have deployed 'ahk2exe' and 'AutoHotkeySC.bin' with my application and did the following:
When a user assignes a new 'hotstring':
Kill 'hotstring' exe script file if running
Append new hotstring to the script file (if non exist then create a new one)
Convert edited/new script file to exe (using ahk2exe)
Run the newly converted script exe
(somewhere there I also check if the hotstring has been already assigned)
However, I am not totally satisfied with this method for the following two main reasons:
The extra resources deployed with the application.
Lag: The time it takes for the system to kill the process and then restart it takes a minimum of 5 seconds on my fast computer and more on other computers. That amount of time is much more than the time it takes the user to assign the hotstring, minimize/close the window and then test his/her new hotstring. When the user does so initially with no success they will think the process failed. So this method is not very good for user experience.
So, I am looking for a different method or implementation. May be using keyboard hooks? Or maybe adding a .dll library that achieves the same. Are there any resources you know about that might help (free or commercial)? What is the best way to achieve my desired goal?
Many thanks for your help.
Implementing what Autohotkey does would be a pretty non trivial task.
But I'm pretty sure that AHK supports an "autoreload" option for scripts
googling "autohotkey auto reload" turned up several pages discussing that very concept. IF that worked, all you'd have to do is update the script file and that's it, AHK should automatically reload the script.
I am writing a custom xulrunner-based app and I wish to have some files deployed in the user profile the first time the application is run.
I placed the files in my application's defaults/profile directory but they did not get copied to user's profile during the first run of the application.
Should I write some additional code or this should happen automatically?
The thing that gets copied for sure is the application default preferences.
Is there a "standard" way offered by Firefox or some of the many mozilla applications?
Any link to some reading will be helpful.
Any hint is valuable.
Thanks in advance.
Unfortunately the standard way of doing first run code is to use the pref system to determine if you have or haven't done something yet. There are a few gotchas though:
Make sure this code only runs once. If your firstrun code is in an overlay or main browser window, it can be run multiple times (once per window)
after you run the code and set the pref, make sure you flush the prefs, since prefs are written on close and will only be saved when you close.
Components.classes['#mozilla.org/preferences-service;1']
.getService(Components.interfaces.nsIPrefService)
.savePrefFile(null);
You could also use the preferences system in concert with querying for an extensions version number. When the version changes, call your function. That would allow you the flexibility to call the function again later if you want - but only at a version change.