Can we use or access shared object stored in another system?
I'm storing some data in shared object in one system can i access that shared object data from another system?
I think Shared objects are stored in local machine. Can we give the path to (specified system ie server)where the shared objects will store, and can we access that object through same path?
Short answer, no. getLocal will only access the local filesystem, while getRemote is only for connecting to a flash media server (or equivalent).
Try setting the second argument of SharedObject.getLocal() method to the path where the shared object is stored. flash.net.SharedObject.getLocal()
Related
I used a shared object class to save some view data. When I move the SWF file, all the shared object data is lost.
The questions are:
Is this expected behavior of sharedobject class?
Is there any other way to save data that stays with the local or SWF.
SharedObject Data is stored on the local machine, in a specialised sandbox. If you move SWF to another machine or launch it in another OS (i.e. in a virtual machine) of course you will not have the same SharedObject data available. This also applies to launching SWF from a browser (SO data is still saved locally. Acess the same site from another machine and it will be gone).
I have a flash application which runs on web. I need to store images and audio files onto the clients local disk(don't want to store on web) without prompting the client. I have already tried with shared object. But since shared object space is limited to 100 KB per domain I am searching for alternatives.
If someone has better solutions please let me know.
Thanks.
You can't do this with the Flash Player by itself. SharedObject and FileReference/save() are intentionally designed to allow the user to have authority over local storage. It would be a security concern if users did not.
Using an AIR application, though, you can do this using File and FileStream, or EncryptedLocalStore.
I had the same problem with creating log files and writing to them
The only solution for me was to create a localhost WebService (used WCF), so i could use URLRequest to the localhost and pass data to service - which then updated file or created it.
But in your way, if you want to store things from the user to your disk, maybe you could also somehow play with the Web services. Just need to try.
Visual studio has almost complete Web service template - just edit for your purposes.
I want to store basic information for a action script flex app. Normally I would just have a simple application.ini file where this config resides. Is there an inherent way that I can store this kind of information so that when I close an application and open it again, it knows what I changed a variable to? Ideally, without having any config files lying around? Perhaps it can store it in registry or another way?
Ideally, without having any config files lying around?
Shared object will help you to store some information. I don't know how big is your data, but SharedObject is great for storing flags and states.
The SharedObject class is used to read and store limited amounts of data on a user's computer or on a server. Shared objects offer real-time data sharing between multiple client SWF files and objects that are persistent on the local computer or remote server. Local shared objects are similar to browser cookies and remote shared objects are similar to real-time data transfer devices.
We have developed a consolidation function that will be used by other processes and want to position the function in its own MDB (call it "remote") so that it can be referenced and called from "caller.mdb" when its needed. The function is designed to return an array and works great when executed called directly from within "remote." However, with "remote" properly referenced in the "caller" VBA project, when "caller" makes the call the function returns errors. We get a variety of errors such as
3078: Jet cannot find the input table or query
QUESTION. Within "remote", how does one properly set references to the db and its local objects (e.g. one table and several queries including INSERT and UPDATE queries)? CurrentDB is apparently not the answer; we have also experimented with the AccessObject and CodeData objects. "Remote" and "caller" currently reside on the same drive, so that wouldn't seem to be the problem.
Instead of CurrentDb you could use with CodeDb wich points to the mdb currently executing the code.
Set db = CodeDb
The way Access itself does this (with all the wizards, which are all programmed in Access), is to use Application.Run. It does mean the code you're calling has to be a function, though it doesn't matter what it returns. Application.Run requires no references, just a path:
Application.Run("MyCodeDatabase.MyFunction()")
Obviously, if the code database is not in the path that Access uses (which includes its own app folders (including the app-specific folders in the user's profile) and the folder where your main application front end is stored), you'll need to specify the full path.
Application.Run() is a function that returns a value, but it is typed as variant. This may or may not work with your array. It's not clear from the object browser whether or not the arguments are passed ByVal or ByRef, but if they are ByRef (which is what I'd expect), you might just pass the array in and let the function work on it and then use it after the code in the remote database has completed.
On the other hand, the arguments are probably variants, so there's not much difference between that approach and just using the structure returned by Application.Run().
Marcand gave you the answer to your immediate question. There are other problems and irritations when it comes to using add-ins or referenced Access databases. See my Add-in Tips, Hints and Gotchas page.
There are a number of differences and nuances to calling forms and functions through a reference in a another MDB or ADP. I have run into issues in both situations, and what you are referring to as the "remote" database, I refer to as a central library.
At my Tips and Tricks page at http://www.mooresw.com/tips.php, I have pages devoted to programatically changing references, getting Access to search for the referenced file instead of having a broken reference, and calling forms through a reference.
Programatically changing references is needed when you publish the database from the development environment to the user or production environment. When working in the development folder, it's fine for the program to have a reference to the central library directly, but we wouldn't want code that 20 users are running tying up the central library in our development area. (An MDB file opened through a reference gets locked just as though your users were opening it directly)
The situation of running a form in a central library (or "remote" database) where there are no links or tables can be tricky. In that situation I've chosen to open a connection to the "caller.mdb" using ADO code with a Jet connection string in the open event of the forms. Doing so provides the ability for the code in the form (or functions in the library) to gain access to the tables and queries in the calling mdb.
For further information, see my pages at the tips link above, and in particular, see:
http://www.mooresw.com/call_a_form_in_another_MDB_through_a_reference.php
which I believe is most relevant to your situation.
Some projects have properties have miscellaneous settings such as: "AllowPayments", "ShowSideBar", "SectionTitle". Really things that don't necessarily fit in to other objects.
How do you guys store these kinds of values? ApplicationSettings? Flat File? Database table?
How do you access them? Static object with properties? DB call?
Would either of these change if you were in a load balanced environment where you would have to synchronize the files across multiple servers?
Environment
ASP.NET 2.0
For me it depends on the context the setting is. If it relates to the data and the domain, i store in the database, if it relates the the application i store in the web.config.
App.Config, or a custom xml configuration file and config service. Key value pair mappings keeps things very simple.
Since you didn't tell which environment you use:
In .NET applications, I use the ApplicationSettings system from Visual Studio. This way you can configure the settings with default values in the designer, and a strongly-typed class to access the values is generated. I usually add a second ApplicationSettings element with the name Persistent in addition to the default Settings, with anything the user configures to go in the Settings object and anything I just save (i.e. window position) to the Persistent object.
This goes for desktop applications.