I work with multiple Explorer windows that use different user credentials and I was wondering if there is a way to set a static title for each window to be able to determine which one uses which user credentials, like window A title set to "user abc" - since the titles change to the currently opened directory which is rather confusing sometimes with multiple windows open
I'm looking for as simple solution as possible, batch, VBScript, etc., something that can be easily ran from either a command line or a script file that doesnt need any compilation, conversion or specific software installed, for example:
open explorer.exe title="custom title"
So far I wasn't able to find any scripts that could handle that - 3rd party applications are out of the question.
Not sure if it's even possible, tried to find anything for few days now to no avail.
According to here its possible to do it for iexplorer (internet explorer)
so by a blind guess it might be possible to do it the same way for explorer
windows>run>regedit.exe
HKEY_CURRENT_USER > Software > Microsoft > Windows > CurrentVersion > Explorer and a new data with string as value type and window title as value name
And by changing theme it is possible to achieve a same or maybe similar objective, everything explained here could be done with a batch script
Related
How can a website be added to Microsoft Edge's "Don't Clear" list (edge://settings/clearBrowsingDataOnClose) using PowerShell, or command line registry key additions from a batch file, or some other method using tools built into Windows (so no external tools that must be installed).
The reason is that Edge is set to clear all browsing data on close, except data for a list of specific websites. It is tedious to add multiple entries manually when a Windows (11) image is rebuilt for a repetitive test scenario.
Thanks
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^^
I am extremely new to Ms-Access. I have a central back end access database in server computer. And all the users have the front end user interface installed on their system.
Now, whenever I make any changes to the interface in my local, i need to re-install the updated interface on each of their system. Is their any way that i can do so that i will make the changes only on my local and it will be automatically reflected on all the users' systems.
Thank you.
Ok there are a couple of options that you can do to either fully or paritally automate this process.
Partial Automation
If you don't have a lot of users and you don't want to do a great deal of coding you can write a simple batchfile or vbs file which you set up on the users desktop as an icon. Batch file code would show the following type of information.
#Echo Off
REM Copy your file from server location to local user machine
xcopy "F:\ServerDirectory\databasename.mdb" "C:\ClientDirectory\databasename.mdb" /E /Y /R
Set this up on the users machine as an icon and whenever you want them to update their front end ask them to double click the icon. This will overwrite their client with whatever you place in the location on the server. It is advisable to create all table links to the database back end having UNC paths as well.
I have used this successfully for various applications - I make changes to the front end place in appropriate location on the server and then do a quick e-mail to people just to ask them to double click the bat file icon.
Full Automation
Programmatically set version control up using visual basic so the client checks version number of the client against a server number and if the client is not the latest will download a new version.
This is more involved and full instructions are available here.
Front End Auto Update
When you deploy an MS Access solutions like this, you need to decide whether to share the client MDB file between all users, or distribute copies to each user. It sounds like you have taken the second option. Each choice has merits and disadvantages. If you stay with the current approach, you might look at a scripting option to deploy updated client MDB files between users.
I've been trying for a while now to get a reference file to be loaded externally to no avail.
To be specific I am trying to load a "Microsoft Date and Time Picker Control 6.0(SP4)" which usually resides in C:\Windows\System32\MSCOMCT2.OCX
However some people that run a macro containing this element don't have that "MSCOMCT2.OCX" file on their PCs so I thought I will move the MSCOMCT2.OCX to a shared location and reference the code to use the shared one instead (so everyone will have access to it)
I tried doing that but when I was trying to load a reference with "Browse" from a different location it didn't load it - because I already had that in C:..
So I thought OK... I will remove the file from C:\ so I can only reference the shared file. - so I deleted it.
So I open the workbook again and look at references - I cant find "Microsotft Windows Common Controls-2.6.0(SP4)" - great!
And I proceed to add it manually with Browse from the shared drive.
When I do that however 2 references of "Microsotft Windows Common Controls-2.6.0(SP4)" are being added - 1 from C:\(which is not there) and 1 from the shared drive.
The one from C:\ is always automatically selected.
If I try to disable the one from C:\ and enable the one from the shared drive it automatically changes back to what it was when i press OK.
If I try to enable both - it says duplicate References and keeps only the one from C:\
So.. does anybody know how can I get rid of that C:\ reference from the list so it doesn't get loaded? Apparently deleting the files themselves did not work.
Ultimately my goal is to enable people without C:\Windows\System32\MSCOMCT2.OCX file to be able to use my Date Picker Tool.
Thanks a lot!
ActiveX control rereferences are always GUID-based. The VB IDE shows you the current location of the file as listed in the registry on your computer, as a courtesy, but it really doesn't matter what it says. The control will be loaded from wherever it was registered on the user's computer.
That's the key: the control must be registered on the user's computer.
I must strongly discourage you from doing what you're trying to do. You might be able to concoct a method by which you load the DLL from a network location, but it presents no advantage over doing the Right Thing(TM), and plenty of problems. The Right Thing is simply that if you need that control, you must distribute and register it with your application, just like everybody else does. And you really should install it in the recommended location for it (System32); not on the network.
Here's a quick example of what can go wrong: you provide your user with you app, and it works with the control on the network like you want it. Then the user installs another application that happens to need the same control. The app's installer sees that the control is already registered on the user's computer, so it doesn't try to add it again. Except that this particular app is intended to be used when the user is not connected to a network. Now you just broke someone else's program.
The VB/VBA architecture was never intended to support XCOPY deployment. I'm know it's a pain and that these extra steps are extremely inconvenient when you're just trying to deploy a "macro". Sadly, it's the nature of the beast. I'm sorry
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.