GeoTagNinja
GeoTagNinja copied to clipboard
nemethviktor
Restructuring FrmMain, Switch to Sync Processing, Introduce Locking
Hi!
so this is what I've done so far... Sorry for the huge PR also touching multiple topics. That's bad behavior...
From what I'v seen and open from https://github.com/nemethviktor/GeoTagNinja/pull/80:
Suggestions
- Base Request_LVW_SelectAllItems (ctrl-A logic) on Request_LVW_HandleSelectionChange
- Make more clear what variable FolderName versus textbox of folder does (not obvious which does which)
Questions
- FolderUp logic is based on textbox. When text box is set manually and change aborted (e.g. due to unsaved changes), folderup will be based on wrong contents of text box. --> use parent folder as set in item?
- How to handle tmi_File_Quit_Click when something is locking / running
Open
- [ ] Replace play code of sending through pipe with actual data
- [ ] Introduce /singleton cmd line param
- [ ] Replace play code of receiving through pipe with actual reaction
- [ ] Double check handling of abondendemutex exception (should we at least post a msgbox?)
- [ ] Testing :)
.... as the change is rather large, we might throw in more pieces to have them tested along?
Changes
- Refactored HelperExifExifToolOperator
- Factored out sep. output handler per type
- Restructured HelperExifExifToolOperator to support sync invocation
- Made all actions by the user synchronous
- Change in RunExifTool --> don't use task and async constructs anymore
- Changed all function calls to sync invocation
- Restructured FrmMain, extract logic from handlers to Request_* methods (reduce redundancy)
- Esp. between menu and task bar handlers, as well as list view mouse and keyboard actions, keyboard and task bar
- Moved all behavior (Request_*) methods to separate code region
- Request_* methods implement locking
- Introduced locking with a basic monitor implementation GTN_Monitor
- Monitor supports re-entry, info on who holds lock
- For locking, all Request_* methods use it
- Some Request_* methods pass on the lock to called methods
- Generic function to get lock incl. info in status line if not acquireable
Minor changes
- Added logger to some classes
- Changed initiator of RunExifTool to enum
- Removed some variables that were not used
- Beautified variables region inf FrmMainApp
- Fixed issue that saving to XMP file did not scroll to correct LVW entry
- Increased decoupling of ListViewPasteGeoData (all variables now are passed in)
- Added some docu
- Removed imports not needed
- Fixed erroneous argument passing to RunExifTool in ExifWriteExifToFile
- Removed dead code in DE.HasSpecificAttributeWithVersion
- Fixed some nullable semantic used for non-nullable types in DE
Apologies, I keep not replying to this one, boo me. Regarding your Qs:
- FolderUp logic is based on textbox. When text box is set manually and change aborted (e.g. due to unsaved changes), folderup will be based on wrong contents of text box. --> use parent folder as set in item? Yes that's a good idea, thank you
- How to handle tmi_File_Quit_Click when something is locking / running --> I think we have two options here. One is that we disable that particular bit while the lock is running. The other is that we poke
private async void FrmMainApp_FormClosinga little to ensure there is no locking going on (and if so then just wait till it finishes) and associate the two together. Basically we don't want the user to quit the app while there is a lock ongoing unless they are smart/stupid enough to task-manager-kill the app
I'm not doing any coding atm hence I haven't merged this (as it's not interfering with anything I'm [not] doing, though if you'd prefer I can merge it, I'm easy either way)
I've updated FrmEditFileData - it's a simple change, you won't have issues merging it as it's a literal one-count if-statement. I realised we were making the code loop through a lot of unnecessary hoops.
I think I managed to get your code up to date with Dev (as I'm about to check in a bunch of things there.). If not, feel free to revert.