How to get the key of a especific directory in the registry of windows XP?
I'm using Delphi
HKEY_CURRENT_USER\Software\Microsoft\Windows\ShellNoRoam\Bags
There are no directories in the registry. The registry contains keys and values. The values have names and data. The keys are like directories, though.
If you want to inspect the contents of a key, you can use the TRegistry class. Set its RootKey property to HKey_Current_User, and use its OpenKeyReadOnly method to open the subkey. Then you can use the various Read methods to read the data of any value.
If you're not sure what the type is of a data entry, you can use the GetDataType orGetDataInfo` methods.
To read a list of all the data entries' names, you can use GetValueNames.
All of those are documented in the help, and now that you know their names, it should be easier for you to find many examples.
Related
I Would like to know if the Genexus Extension SDK already implements something to store persistent data locally (KB Independant and per KB), something like PersistentDictionary from ManagedEsent
I know that genexus uses SQL Server to store KB Related information, is there an interface for me to extend that?
I want to save data per genexus instance (locally) and use that data to load my extension config, everytime the users executes Genexus.
We don't use PersistentDictionary. I would advice not to use it, as it's a Windows specific API, and we are trying make everything new cross platform, as part of our journey of making GeneXus BL run on other OS.
There are different options of persistence, depending on the specific details of your scenario.
If you want to store something like configuration settings for your extension, you can use the ConfigurationHelper class located in Artech.Common.Helpers. This class provides read access to the configurations defined in the GeneXus.exe.config file in the GeneXus installation folder, as well as read/write access to the Environment.config file located in %AppData%\GeneXus\GeneXus\<version>\Environment.config. Note this file depends on the current user, and is shared between different GeneXus instances of a same main version.
The ConfigurationHelper class provides operations to read and save settings of basic types string, int and bool.
const string MY_EXTENSION = "MyExtensionSettings";
const string SETTING1 = "Setting1";
const string SETTING1_DEFAULT_VALUE = "This is the default value";
const string SETTING2 = "Setting2";
const int SETTING2_DEFAULT_VALUE = 20;
string setting1Value = ConfigurationHelper.GetUserSetting(MY_EXTENSION, SETTING1, SETTING1_DEFAULT_VALUE);
int setting2Value = ConfigurationHelper.GetUserSetting(MY_EXTENSION, SETTING2, SETTING2_DEFAULT_VALUE);
// Do something and maybe change the setting values
ConfigurationHelper.SetUserSetting(MY_EXTENSION, SETTING1, setting1Value);
ConfigurationHelper.SetUserSetting(MY_EXTENSION, SETTING2, setting2Value);
If you want to store something in a file based on the current opened KB, there's no specific API that'll help you handle the persistence. You can use the properties Location and UserDirectory of the KnowledgeBase class to access the KB location or a directory for the current user under the KB location, but it's up to you the handling of the file. You'll have to decide on the file format (binary or text), file encoding in case of text files, and handle all read and write operations to that file.
We use the kb.UserDirectory path to store non-critical stuff, such as the set of objects that were opened the last time the KB was closed, or the filter values for different dialogs.
In case you'd like to store settings inside the KB, there are plenty of options.
You can add properties to existing objects, KB version or environment. Making it a property doesn't necessary mean you'll have to edit the value in the property grid, although it's usually the way to go.
You can define a new kind of entity. Entities are the basic elements that can be stored in a KB. The entity may be stored depending on the active version of the KB, or may be independent of the current version. Entities can have properties, whose serialization is handled by the property engine, and also can read and store a byte array whose format and content will be handled by you.
You can add a part to an existing object. For instance you may want to add a part to Procedure objects. In order to do this you'll have to extend KBObjectPart, define your part in a BL package, declare that the part composes objects of certain type, and provide an editor for your new part in a UI package. KBObjectPart extends Entity so the serialization of the part is similar as in the previous case. A caveat of this option is that you'll also have to handle how the part content is imported, exported, and compared.
You can add a new kind of object. Objects extend the KBObject class, which extends Entity. Objects are not obliged to have parts (for instance the Folder object doesn't have any). When choosing to provide a new kind of object you have to consider a couple of things, such as:
Do you want to be able to create new instances from the new object dialog?
Will it be shown in the folder view?
Can it be added into modules?
Can it have the same name as other objects of different types?
As a general guideline, if you choose to add a new property, add it to objects, versions, or environments, not parts. Adding properties to parts is not so good for discoverability. Also if you choose to add a new kind of object, even though it inherits from Entity which as mentioned earlier can read and store a byte array, it's preferred to don't use the byte array in KBObject and add a KBObjectPart to it instead. That way the KBObject remains as lightweight as possible, and loading the object definition from the DB remains fast, and the blob content is loaded only when truly needed.
There's no rule of thumb. Depending on the specifics of the scenario, one option may be more suited than others.
Documentation states that keys must be passed explicitly, so if using Redis cluster, the command can be forwarded to the appropriate node.
However, does this apply to new keys as well? For example, if I have a script to register a new entity, and such script is creating dynamically a totally new key composed by the result of INCR and a literal, would it be a problem for Redis cluster?
The alternative would be to call to INCR in a separate operation and pass the key to the script as KEY[1].
If you're careful to ensure that your new key is hashed to the same server as your other keys, I think you'll be fine.
That is, the important thing with Cluster is not just to declare your keys up front, but to make sure that all the keys your script operates on are located on the same server. You can do that with your keys by using hash tags. If you construct your new key in such a way that it hashes to the same slot as your others, I think it will work fine.
I have a command object that I want to convert into a domain object.
However, the object I want to convert the command object into may be one of two domain classes (they're both derived classes), and I need to do it in a service (which is where, based on other data, I decide which type of object it should be bound to). Is this possible and what's the best way to do this? bindData() only exists in a controller.
Do I just have to manually map command object parameters to the appropriate domain object properties? Or is there a faster/better way?
If the parameters have the same name, then you can use this question to copy the values over. A quick summary can be as follows.
Using the Grails API
You can cycle through the properties in a class by accessing the properties field in the class.
object.properties.each { property ->
// Do something
}
You can then check to see if the property is present in the other object.
if(otherObject.hasProperty(property) && !(key in ['class', 'metaClass']))
Then you can copy it from one object to the other.
Using Commons
Spring has a really good utility class called BeanUtils that provides a generic copy method that means you can do a simlple oneliner.
BeanUtils.copyProperties(object, otherObject);
That will copy values over where the name is the same. You can check out the docs here.
Otherwise..
If there is no mapping between them, then you're kind of stuck because the engine has no idea how to compare them, so you'll need to do it manually.
I would like to execute a job that requires that I save a type in the JobDataMap. This will later be used along with the ID of an entity to rehydrate the entity so the job can use it.
I know I could get the AssemblyQualifiedName of the type and store that, then use GetType() in the job, but before I go down that path, I thought I'd see if quartz just does this for me.
If I put a type in the JobDataMap, will it serialize and deserialize when I access the property later?
Sure it will. You can use the JobDataMap indexer to store arbitrary data. Type instances are quite safe, but you need to be extra careful about versions (using only assembly qualified name removes this problem), namespaces and public keys.
If there were a slight possibility that the type might change after persisting I would recommended using a 'meta name' like 'BackupJobHelperType' that you would then resolve to the actual type. Generelly always prefer simple serialization safe types over own types, if possible set quartz.jobStore.useProperties to true which will enforce string key and values.
You can save the info when building the job and it will be available when the job starts.
I have a database application project written in Delphi XE and connected to MySQL Database using dbExpress. I use JVCL grid Components to show the records from the Dataset. It will be more efficiently if I can use another JVCL Components to do the FormStorage.
I've been suggested to use TJvFormStorage and TJvAppIniFileStorage for form storage. I have many forms on this project so I need to adding new section in my INI file to store the form size values but I don't know how to do that using TJvAppIniFileStorage.
The TJvAppIniFileStorage is just providing the DefaultSection() method which means it's just can modify and write into one section only which declared as the default.
Anyone can describe to me how to adding new section using the JVCL's TJvAppIniFileStorage?
Thanks in advance.
Is the TJvFormStorage instance the one that determines in which path of the abstract storage to put the data about this form, with the value of the AppStoragePath property.
You can use the special value '%FORM_NAME%' to determine that path automatically at run-time. The '%FORM_NAME%' is changed for the real .Name property of the form where the component is located, or if it is a frame, a dot list of the frame chain up to the form containing it. That way you can have different instances of the same class saving the info to different paths.
When you're using a TJvAppIniFileStorage instance as the data storage backed to save the form data to a INI file, that path is equivalent to the INI section where the information is stored.
In other words, if you want to store the info of your form in a section called 'MyForm', set that value to the AppStoragePath property of the TjvFormStorage instance in that form.
Use the Source, Luke! ;)
My guess is: It uses Parent.Name or Parent.ClassName to store parameters.
Another point: take in mind several monitors on user's computer. Almost no app takes in mind this case.