I am trying to get this IndexedDB stuff working in a Metro (Windows 8) app, using JS.
I thought I was good, but then I ran the WACK tool a couple of times, just to see if I ran into any issues.
After these tests the IndexedDB.open call no longer opens my database (which has 7 entries in it) instead it fires onupgradeneeded, and gives me a blank (new) database (since I create an object store in the onupgradeneeded handler).
I did not change my version number, I did not change the database name. So I am guessing the applications domain somehow changed during the WACK tests.
Does anyone now how to get my database domain back?
One of the things the WACK test probably does is doing a fresh install of the app checking if everything goes fine. So when the app is installed for the first time you have to provide a creation of the database, this is done in the onupgradeneeded event.
I think you forgot to provide this, and that is why he creates a new blank database. Instead of a new database with the required structure.
Related
So in my company we have this huge website project in Visual Basic. On this problem we have two parts involved, the admin, running at one port in local, and the website, running on another port.
The problem I have is that when I change a user's property in admin, it calls the function to save the user and adds the changes to the database. After that, we run a HttpRuntime.Cache.Remove(key) and it is removed successfully. BUT when the website part tries to get the user from cache (before doing so from the database), it gets it successfully, even though it was removed previously. So my question is if this is a thing, if it's possible that even though using the same code, there are 2 different caches, I've done several tests and the cache is removed successfully from the admin part, it's definetly not a code problem.
So apparently, that's how it works. If the same project has 2 or more applications running at the same time, each one has its own cache, even if they share the code that removes or adds things to cache. There is no mistake, the answer would be to create a function that clears the cache from the other applications.
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
When creating Metro applications in XAML/C#, how do I detect when the application is first installed or run for the first time since installation (or potentially upgrade)? I need to use this opportunity to ensure that my database schema is correct and potentially synchronise some base data.
I had hoped that I could pick this up from the LaunchActivatedEventArgs within the OnLaunched method, but there does not seem to be a valid value for the Kind or PreviousExecutionState that I can use.
Thanks.
http://msdn.microsoft.com/en-us/library/windows/apps/windows.storage.applicationdata.localsettings.aspx#Y0
When your app starts, write a setting called "AppHasBeenStarted" or something to LocalSettings. If the setting has not already been written, you know your app hasn't been started before. And you could improve on this, by making it "AppVersion", and writing the app's version. This way your app can detect upgrades by comparing the stored version with its own version.
It would be useful for many people to know how to completely remove an application from your device when testing.
I have downloaded my app many times now, and likewise have deleted it many times. The problem is when deleting the app, it does not remove things like the persistent object related to my app, or the images downloaded through the app. So, when I download the next build, I have no idea if something broke that is related to building the persistent object or fetching the images since those elements already exist from the last build.
I don't know if this is a cache thing. I don't know if this is expected and I have to use some utility to wipe this data after deleting the app. I can't really find much info through basic web searches.
Any information would be appreciated.
Blackberry Bold 9000. 4.6 OS. tested with both SD card and no SD card.
Objects stored in the PersistentStore are automatically deleted on uninstall if their interfaces were defined in your project. If they are from the standard BlackBerry API then they will stick around until they're deleted. E.G if you save a String in the PersistentStore it will stay in the PersistentStore but if you save a class you created it will be deleted on an uninstall. So if you want to have those objects be deleted automatically just create a wrapper class and save that.
Images stored on the filesystem will not be deleted until you or some application deletes them. However, it should be easy for you to write an app that clears everything out.
Another solution you could implement is making your app somewhat self-aware of its data.
Create a simple String value that you persist (or optionally, persist it in a Hashtable so you can store many properties this way) that includes "Version".
At startup of the GUI app, compare the stored "Version" against the application's current version. If the stored version doesn't exist, or if it exists and matches, take no action.
If it exists and does not match, automatically clean up old persisted data; or alternatively prompt the user to see if they want that data to be deleted (which one is better will depend on your implementation)
You can also use CodeModuleListener to listen for an uninstall event -- when that happens, you can clean up at that time as well or instead.
(As an aside and a bit of shameless self promotion, I am actually currently working on a shareable library for Blackberry that makes managing persistence much easier, as well as desktop data backup/restore. I'm doing this as part of the BBSSH project, but I'll be splitting it off into a separate library of core components and publishing it under a dual GPL/optional commercial license. It will contain hooks for data cleanup and data versioning. )
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. ;)