Closed dEhiN closed 7 months ago
See issue #10 for more details
Even though I'm the only one currently working on this repo, it's probably a good idea to get into the habit of updating issues. So, currently while no data is actually saved to disk yet, the function to save the data is coming along well.
It calls the function generate_user_edited_data
which needed to be coded in anyway, as it will help with other overall functionality. This function handles 4 scenarios:
Currently, scenarios 2-4 are handled by generate_user_edited_data
. None of the generated JSON data is saved to disk yet, since scenario 1 still needs to be added in.
In testing out the existing code to make sure that scenario 1 works correctly, discovered a bug. So far, for all my testing of the save functionality, and specifically the generate_user_edited_data
function, I've been using startup item 2 from the default startup data, which is the following:
{
"ItemNumber": 2,
"Name": "Google",
"FilePath": "C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe",
"Description": "The Google Homepage",
"Browser": true,
"ArgumentCount": 3,
"ArgumentList": [
"--profile-directory=Default",
"--new-window",
"https://www.google.com/"
]
}
This startup item has existing arguments, so the tests have been working to add a new argument, for example. However, I tried with startup item 1, which doesn't have any arguments, and while the argument count key/property gets updated, the prettify_startup_item
function runs into an error. Will need to fix this.
Created issue #15 to work on this.
Currently, the save function prints out that the functionality isn't yet implemented. Will continue to work on this.
As of March 2/23, the save function only pertains and shows for a single startup item. While testing, I discovered that when editing the startup file, while changes made to more than 1 startup item is retained in memory while the program is running, it's not possible to save all the changes. When saving the changes to 1 startup item, the text file that the changes are printed/saved to will use the default or original JSON data for the other startup items.
For example, say a user follows the following steps:
The user could then switch between selecting to edit item 2 and 3, and then choose the option to view the startup item, and the changes in steps 3 and 5 above will be retained. However, the only save option in the menu for editing a single startup item. If this option is chosen for item 2, then the original JSON data will save for item 3. Conversely, if the save option is chosen for item 3, then the original JSON data will save for item 2.
Debugged and stepped through to see what's currently happening. In the stack, when going through the menu to edit a single startup item, the following happens:
demord > json_editor() > edit_startup_item() > edit_startup_item_arguments_list() > add_startup_item_arguments_list()*
*the last function for when a startup item has no arguments
As already mentioned, currently the only save option is in the menu for editing a single startup item. The problem is that the function json_editor
holds a reference to the full startup data dictionary including every changed startup item. So, if items 2 and 3 are changed, when the program flow goes back to json_editor
, the dictionary json_data
will have both updated items.
But, when the function edit_startup_item
is called, only the specific item chosen is passed through. Additionally, currently, when the save function is called, the function edit_startup_item
passes onto the save_startup_item
function the same specific item chosen. The save function then calls json_reader()
to read in the original JSON data. This is what causes previously edited startup items to not be saved.
Possible solutions:
json_editor()
so it's not possible to save an individual startup item after editing it, but only always the full startup datademord
to hold the persistent startup data, which can then be updated as needed as well as used throughout the programThoughts on the possible solutions:
Solutions 1 and 2 may potentially involve rewriting existing functions. For example, with solution 1, if it's only possible to save the whole startup data dictionary, then the functionality to determine which type of save operation is unnecessary. While it can be erased, there's probably no need. A similar situation occurs with solution 2.
Solution 3 is probably the original idea I had in mind when creating the save functionality with all the logic to determine which type of save operation, to allow for and choose different scenarios, etc. The save function probably doesn't work fully at this moment because, in order to confirm the updated startup item data would be saved, I modified the save function to write the original JSON data, the original startup item, the changed startup item, and the changed JSON data (with the changed startup item) to a text file.
If, instead, I have the save function properly save the changed JSON data, then, when the save function is called after editing another startup item, the JSON data read in by json_reader()
will be the changed data instead of the default startup data. I will need to test this. However, if this works, I could still implement solution 1, or at least, add a save functionality to the json_editor()
menu.
Changed the issue title to reflect that it's for a single startup item. This issue is now complete.
Currently, when choosing to edit an existing startup item, it's possible to change the name, description, program path, and even arguments. This includes editing, deleting, and adding arguments. However, while there's a menu option to save the (modified) startup data, currently, a message is printed out that the functionality isn't available yet.