• SONAR
  • Another little utility for you (p.8)
2015/08/30 03:20:14
KPerry
It's compiled for x64 only - I'm only able to practically test on Windows 7 and Server 2007 (at some stage I'll go to 10...when I have time!).
2015/08/30 16:15:53
DRanck
I'm running a 64-bit PC and have the latest version. It should work when compiled for x64. Perhaps there is a dependency I don't have. I don't have dependency walker installed here. If I get a chance this week I'll run it see what comes up.
 
Thanks,

Dave
2015/11/19 04:29:13
Elffin
I can confirm its not working for windows 10  X64.
Looking forward to an update when your ready!
2015/11/19 06:45:09
KPerry
No Windows 10 here so no way to update.  Sorry.
2015/11/19 08:44:51
Noel Borthwick [Cakewalk]
Cool does it add itself to the tools menu?
2015/11/19 09:31:50
KPerry
No - it could though (although needs elevated privileges I think?  I hate dealing with elevated privileges in .NET :-)).
2016/01/04 04:21:06
ChristopherM
@Mudgel - could you add a note about incompatibility with Windows 10 alongside your download link, please?
2016/01/04 11:53:25
Willy Jones [Cakewalk]
Kevin -
 
any chance you'd consider putting the source on github? You might get a few contributors/volunteers ;)
2016/09/14 01:51:04
robert_e_bone
KPerry
Reg file will save everything, including fields that aren't user-editable; it's perfect for a backup.  But if you want to edit "safe" fields such as names or transfer settings to another computer (or user), the XML is probably safer.


You may have address this later in the thread (perhaps page 2 or 3), and if I missed that I apologize.
 
I would think that if you had a process that ran as a user-triggered rebuild/recompile/data-update-function, then you could read an external file that contained your internal tables, or however your data is set up for the execution of the code.
 
So, rather than build up whatever internal data you are working with, that slows your current process down - doing it every time someone runs it, you have a separate process or some menu option when the utility starts, or done outside of Sonar altogether, do that process ONCE, and save everything that way, so it doesn't have to rebuild the same thing from the same data, every time.
 
Them, whenever an updated set of data needs to be absorbed by the utility, the user could run/trigger the functionality to rebuild the internal data and save the data in a single update run.  This way, the MAJORITY of the time, the utility would run super quickly, and only once in a while require the updating of the internals.
 
I guess you could also just compile up a new version of the utility whenever its internal data needs change, and just release it, and replace the obsolete one.
 
Just some thoughts on it :)
 
Bob Bone
 
© 2026 APG vNext Commercial Version 5.1

Use My Existing Forum Account

Use My Social Media Account