I downloaded the repository and built it with VS Insiders edition. The first time I ran it there was a memory leak. I tracked down the issue and fixed it.
In the two dialogs which deal with images (video and static barcode), the memory was being allocated with a new, but never deallocated with a delete. Furthermore, in the ScanToConnectDlg.cpp file, the ClearImageCache() method was not called in the destructor.
Another memory leak occurred within the EventSink.cpp file. An event pointer was set to NULL and to 0 but the memory was not freed. Probably a result of porting from C# to C++. C++ has no garbage collection.
There was an incorrect variable created as a pointer to a CObject, but the pointer was assigned a 0 value and later used as an integer. There were #pragma boundaries which disabled the warning messages that resulted. Perhaps when this was a 32 bit app it would not be a problem but it could be a huge problem for a 64 bit app. Anyway, I cleaned up that routine and changed the type of map structure to something more type-safe.
Finally, there was a soon-to-be-deprecated /Gm switch. I removed it and enabled the MP switch to allow multi-processor compiling. This should not be an issue for backwards compatibility since these two options date back to VS2015SP1, I think.
I hope this will pass muster.
peterv959
I downloaded the repository and built it with VS Insiders edition. The first time I ran it there was a memory leak. I tracked down the issue and fixed it.
In the two dialogs which deal with images (video and static barcode), the memory was being allocated with a
new, but never deallocated with adelete. Furthermore, in the ScanToConnectDlg.cpp file, the ClearImageCache() method was not called in the destructor.Another memory leak occurred within the EventSink.cpp file. An event pointer was set to NULL and to 0 but the memory was not freed. Probably a result of porting from C# to C++. C++ has no garbage collection.
There was an incorrect variable created as a pointer to a CObject, but the pointer was assigned a 0 value and later used as an integer. There were #pragma boundaries which disabled the warning messages that resulted. Perhaps when this was a 32 bit app it would not be a problem but it could be a huge problem for a 64 bit app. Anyway, I cleaned up that routine and changed the type of map structure to something more type-safe.
Finally, there was a soon-to-be-deprecated /Gm switch. I removed it and enabled the MP switch to allow multi-processor compiling. This should not be an issue for backwards compatibility since these two options date back to VS2015SP1, I think.
I hope this will pass muster.
peterv959