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.
Related
I am trying to test the Login feature of my Android app with multiple user-password entries that I have in an Excel. I have already been able to import that data from the Excel successfully and run the same test with each row (with "Run on all Rows" option), but now I am facing a problem that I am not being able to solve.
After a test runs with one row, one the test starts over with a new row, it will not restart the app, but start at the same point where the previous one finished. I think this is not the expected behaviour, in general, since most of the GUI testing tools restart the app when testing a feature with parametrization (data from Excel, mostly). Anyway, I "fixed" this by logging out in my app.
In this case there was an "easy solution" by logging out. But what if I was testing a different feature in which I cannot simply "log out". The problem is that in those different cases I would have to navigate back or do something that may fail and has nothing to do with the feature I am testing.
I am not sure if I am not using the right approach. Is there a good general solution for this issue?
I would suggest the following two ways to solve your problem if you cannot simply use logout as the last step.
Use App.Launch function you can add one line to the top of your script like Device("iPhone 7").App("myApp").Launch NotInstall, Restart . Here the device and the app can be TO in object repository or identified using descriptive programing like Device("id:=123456")
Check options in Test Settings Please check the latest UFT version maybe 12.53 or later if there are any options in Test Settings for users to choose to restart or reinstall app for iterations.
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'm trying to get acquainted with test automation using Microsoft TFS Api.
I've created the program which runs my test set - it uses code similar to one described here, e.g.:
var testRun = _testPoint.Plan.CreateTestRun(false);
testRun.DateStarted = DateTime.Now;
// ...
testRun.Save();
I believe this forces them to start as soon as any of agents can run them, instead of being delayed to certain time. Am I wrong? Anyway, it works all right.
But I was told by my lead that the task should be started each time the new input files are copied to certain folder (on the network I think, or perhaps in TFS).
So I'm searching for a way which allow to trigger tests on some condition - but currently without any luck. Probably I miss proper keywords.
I only found something vaguely related here but it seems they say it is not possible in a proper way.
So are there any facilities in TFS / MTM, any ways or approaches to achieve my goal? Thanks in advance for any hints / links.
You would need to write a system service (or other) that uses the file system watcher. Then when the file changes you can run your code above.
There is no built in feature in TFS to watch a folder for changes.
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'm working on creating a self updating application and one issue I'm running into on Vista and Windows 7 is needing to have admin privileges in order to update the client. I've run into issues with clients that have their users running under restricted permissions and they would have to have IT log onto every machine that needed to update the client since the users were not able to.
A possible work around I'm considering is to have the launcher application installed into Program Files as normal, and having the real application that it updates installed in the users documents somewhere, so that they could update and run new versions without IT becoming involved.
I'm wondering what potential gotchas I'm missing here or what I should be aware of before heading down this path. I'm aware that click-once does something very similar, and I'd be using it, except I need the ability to do silent updates, without any user interaction.
This is how it is supposed to be. The last thing most IT departments want is a user randomly updating a piece of software. This could have all sorts of unintentional side effects such as incompatibility with the older version's files, new and possibly insecure functionality, etc. This is why IT departments disable Windows Update and do their updates manually in a controlled fashion.
If the users want an updated version of the software they should be requesting it from their IT department. Those computers and infrastructure don't belong to them, they're simply borrowing time on them from the company they work for so they can do their job.
Is there an issue with having only one installation of your program? Is it particularly large, for example?
Do you require admin privileges to run your program?
If not, odds are you don't need the Program Files folder.
I suggest you forgo installing to Program Files entirely and just install your program into the user's folder system at <userfolder>\AppData\ProgramName.
If you happen to be using .NET, look into the ClickOnce deployment mechanism. It's got a great self-updating feature that'd probably make your life a lot easier.
Edit: Just saw your last sentence. ClickOnce can force the user to update.
A couple of things:
If you decide to move your app to some place in documents, make sure that your application writes data transparently to where your program is installed, e.g. if there are hard coded paths anywhere in the code that are pointing to bad places. Perhaps this is not an issue for you, but might be something to keep in mind.
We solved this in pretty much the same way when we decided to implement a "live update" feature. But instead we installed a service which is running with administrator rights. This service in turn can run installers once the program needs to be updated. With this type of solution you don't even have to move your applicaton out of program files.
Cheers !
Edit:
Another neat thing with having a service running as administrator. Is that you could create a named pipe communication with it and have it do things for you, like you wouldn't be able to do as a normal user.
A loader stub is a good way to go. The only gotcha is when you have to update the loader; the same initial problem applies (though that should be pretty infrequent).
One problem that I can think of off the top of my head is that you're stepping outside the entire idea of keeping things more "secure." Since your executable exists in a location that should be completely accessible to a non-administrator, it's possible that something else could slam your exe thus subverting security.
You can probably leverage AppLocker. It may only be for Win7 though I'm not running Vista any more. ;)