I have about 10 different Outlook Rules that I created on the fly to move generic emails from various mailing lists to the same sub-folder.
Now I want to merge them all into one rule with OR statements.
Obviously I can open the Rules wizard and manually edit a single Rule copying the addresses from the other rules into it to merge them together.
However, I would like to see if it can be done programmatically (even if it takes much longer than doing it manually!).
Is there a way to manipulate Outlook rules like this?
VBA perhaps?
You can use a software to do that. An add-in for outlook will do the trick. Power Rules Manager did merge 80 rules and left me with 12.
Related
Can I use redemption.dll to copy the rules
I want to copy exiting profile rules and add them to a new profile. It is possible to use the "redemption .dll"?
Yes, it is possible. Redemption is a wrapper around Extended MAPI which provides everything you are interested in. It is to you which wrapper to use.
Rules are stored as hidden items (associated content) on the Inbox folder of your account. I'd suggest using MFCMAPI or OutlookSpy for exploring Outlook internals and hidden properties.
Already answered at Copy exchange 2013 rules using profman
There is no reason to create multiple questions - better to create a single well formulated question with detailed questions and steps that you have already tried so far.
I have a VSTO add-in for Excel created in Visual Studio that I deploy by installing the following three files on a user's machine:
Company.Excel.dll
Company.Excel.dll.manifest
Company.Excel.vsto
Now, I want to add a VSTO add-in for Word that installs alongside the Excel add-in using the same installer. So, I would maybe expect to add the following incremental files to my installer:
Company.Word.dll
Company.Word.dll.manifest
Company.Word.vsto
Is that (6 files) the best way to do this, or is it better to combine the .manifest and .vsto files into single files, like:
Company.Excel.dll
Company.Word.dll
Company.???.dll.manifest
Company.???.vsto
Any thoughts on which approach is better and why? If it is best to combine them as in the latter case:
1) Does the naming of the last two files matter? In other words, what replaces the question marks in the file name?
2) Any other tips on how to generate a single manifest for this purpose?
I'd suggest not to attempt to rename or merge the .vsto and .manifest file names.
I cannot see a scenario in which renaming this files can be beneficial. While it is possible, there are multiple places which reference these files by their name and you would have to find all and update.
Also I don't see how merging .vsto files would be possible. You'd end up having Excel trying to register the Word Add-In.
And then again, you really can't possibly have any reason with messing with these files.
The way I go with multiple VSTO based add-ins is by keeping all of them separate completely.
Merging them would never be appreciated because it just complicates the process.
If you want to keep the setup scripts simpler then preferred way is to create Merge Modules of each Add-ins separately and then use all those modules in the final setup.
1) Does the naming of the last two files matter? -
Yes, it kind-of does. Please open the registery and go to HKCR(or HKLM)\Software\Office\Word(or Excel)\Addins\Your-Addin-Name
Then, open the Manifest key - You will see the .vsto file mentioned there. The way office add-ins work is, they look up this registery key when they are loading the add-in.
Maybe if you rename .vsto file and change "Manifest" key accordingly, things will work as well but I wouldn't risk it.
2) Any other tips -
I would personally keep those files separate.
We recently switched to team foundation server 2010 for our source code management, everything works just fine, except for some legacy code written in FoxPRO 7 and 9, source code files are some sort of tables. For Forms, there are two kind of files, one ending in .scx and another in .sct, both can be explored using the fox studio but there is no way to open them in a text editor.
does anyone have any experience getting the fox code to work/merge... on TFS ?
I'm not aware of all of the ins and outs for source control and FoxPro, but if some of the source is binary, you can configure file extensions to disallow merges.
Right-click on the collection (root node) in the TeamExplorer window. Go to Team Project Collection Settings | File Types.
You should be able to add the extensions (like .sct), and specify that merging and multiple checkout is not allowed for those files.
The downside will be that only 1 person at a time can check those files out, but since the forms are FoxPro tables, I would imagine that's the same problem that you would have with any source control tool.
For merging you can set up a merge tool that is capable of merging those files. This must be done on every developer station (Tools->Source Control->VS Team Foundation Server->Configure User Tools).
It may be that VS uses a server-side merge tool to do auto-merges, I don't know if or where you can change that.
I've worked with VFP since it was FoxBase back in late 80's. Visual Foxpro used .dbf files (renamed extensions) for purposes of building forms (.scx/.sct) and visual class libraries (.vcx/.vct) and reports (.frx/.frt).
I've written some code to run through a given project and dump out a text version of all the code as if it was all text-based. All the controls are dumped in alpha order, embedded procedures, etc too. List all property settings in same place too.
Its not PERFECT, but I've used over the years in comparing source code versions when dealing with other developers who liked to change things and not notify me (or others) of such changes and finding later by other horrendous means.
If this is something you might be interested in, I can strip-down the code (some) and send it to you via an email, but would need an email address. The code is written in VFP as a .prg file, so nothing compiled that you would need to worry about any viruses or anything.
At least this way, you COULD get a text version associated with the binary pair's of files used within VFP.
In Visual Studio, there are formatting rules found in the options menu that specify things such as where to include line breaks, how many spaces to use when tabbing (or to use tabs instead of spaces, etc.)
Is there a way to push these rules to each programmer's machine using a domain policy or some other way?
Those aren't actually rules -- they're preferences for automatic formatting applied by the IDE as you type. You can share those preferences by exporting them from one VS instance and importing them into another, but no amount of preference application will actually verify the contents of edited files.
If you want to actually apply rules regarding code formatting, you might want to consider using a tool like StyleCop.
http://www.phphosts.org/2010/05/share-the-same-visual-studio-settings-between-team-members/
That does not necessarily ENFORCE things though. You might have to do that in a login script after you figure out where those settings go.
I know that the web is full of questions like this one, but I still haven't been able to apply the answers I can find to my situation.
I realize there is VBA, but I always disliked having the program/macro living inside the Excel file, with the resulting bloat, security warnings, etc. I'm thinking along the lines of a VBScript that works on a set of Excel files while leaving them macro-free. Now, I've been able to "paint the first column blue" for all files in a directory following this approach, but I need to do more complex operations (charts, pivot tables, etc.), which would be much harder (impossible?) with VBScript than with VBA.
For this specific example knowing how to remove all macros from all files after processing would be enough, but all suggestions are welcome. Any good references? Any advice on how to best approach external batch processing of Excel files will be appreciated.
Thanks!
PS: I eagerly tried Mark Hammond's great PyWin32 package, but the lack of documentation and interpreter feedback discouraged me.
You could put your macros in a separate excel file.
Almost anything you can do in VBA to automate excel you can do in VBScript (or any other script/language that supports COM).
Once you have created an instance of Excel.Application you can pretty much drop your VBA into a VBS and go from there.
If it's the Excel/VBA capability that you're looking to use then you could always start by creating all of the code that will interact with the Excel files you're wanting to work on within an Excel file - a kind of master file that is separated from the regular files, as suggested by Karsten W.
This gives you the freedom to write Excel/VBA.
Then you can call your master workbook (which can be configured to run your code when the book is opened, for example) from a VB script, batch file, Task Scheduler, etc.
If you want to get fancy, you can even use VBA in your master file to create/modify/delete custom macros/VBA modules in any of the target files that you're processing.
The info for just about all of the techniques I'm describing I got from the Excel VBA built-in reference docs, but it certainly helps to be familiar with the specific programming tasks that you're tackling. I'd advise that the best approach is to put together your tasks (eg, make column blue, update/sort data etc) one by one and then worry about the automation at the end.