Hello there back in 1999 early 2000 a lot of my apps used this MFC Export dialog extension which added filters to file extensions, because MFC didn't yet have that (at least that's what I remember to be the reason, maybe I was drunk I don't now), the library can be downloaded here: https://www.codeproject.com/Articles/54/Adding-filters-to-the-Open-File-dialog
Now I know that this functionality is built in already, but its easier to fix one library then to fix all of my apps
Now if I compile this with VC++ 6 everything is fine, the problem is that I would like to use a bit more modern compiler
Here are my changes that I added to this lib over the years (its a big file so I will post a link instead): https://pastebin.com/pj0j2nL4
The example code that I use to test this library can be found here: https://www.mediafire.com/file/xz5mxwy2rcmb9h3/FileExportDialog_demo_upg.zip/file
Just click on File->Export and you should see the problem
Now the problem happens on the library's void CFileExportDialog::OnTypeChange() method
is this part
CWnd *fileNameBox = GetParent()->GetDlgItem(edt1);
if (fileNameBox == NULL)
fileNameBox = GetParent()->GetDlgItem(cmb13);
For some reason, GetParent() returns NULL (I cannot even get to GetDlgItem() at this point)) pointer, I have no idea why does it do that, and the strangest thing is that this used to work on VC++ 6 (it also worked on MFC7 as well), why doesn't it work on VC++ 17 (MFC140) anymore ?
Hopefully someone has an idea what changed and how can I fix my library
Thanks for Anwsering and Best Regards
Related
I've recently moved to VS 2015 while I'm still using the vs10 compiler for a project. And yea, I still have not moved this one to unicode So I was typing along, I had just added a member to a class as:
LPCTSTR GetDateFormat( ) const { return strDateFormat.c_str( ); }
Then I went to use it and intellisense offered GetDateFormatA( ). I said, "What the..?", and took it. I was surprised to find the code compiled fine! I searched even though I knew I had no GetDateFormatA( ). I traced in and it took me to my GetDateFormat( ).
I'm at a lose as to find out what this is about with google, what would I search on that would be specific enough to get results?
Update: After sleeping on it and because of Ken White's comments, it occurred to me that GetDateFormat( ) was accually in the Windows API, and so it is. When I typed: pReport->GetDa, intellisense dug into the global namespace and offered GetDateFormatA instead of my member function name. And of course it compiled as the define from GetDateFormatA to GetDateFormat exists.
I've never recalled seeing it before; It is rare to create a member with a name that Windows uses. Defines trump for intellisense.
My program has a very specific error that took me a while to track down - now I don't know how to fix it. My code is very long and in many files and I don't see much point in posting it here.
In the IDE, everything runs fine, in both Debug and Release (with the runtime library set to either /MTd or /MT, respectively, so I'm assuming all dependencies are included).
However, when I run the standalone, I get a crash. At first I thought it was a dependency problem but it doesn't seem so.
At some point in the code, I am accessing a vector via a method call: t->GetList(), where GetList is defined as std::vector<T*> & GetList() and the method simply returns a member variable (simply defined as std::vector<T*> field in the class).
It turns out, if I print out the size of the list while running from the IDE, I get 0 (which is the correct answer in this case).
However, when doing the same thing running from standalone, I get the size as 467467353.
I tried changing the method declaration to std::vector<T*> * GetList() and doing return &field; and updating the rest of the code but this didn't fix anything.
I then tried replacing the member variable field with a pointer, and in the constructor instantiating a new vector and deleting it in the destructor. Still no luck.
So I made a simple test case program that simply made a class with a vector field, and a method to return a reference to it. Then in main I would create an instance variable and getting the vector and printing the size. This worked both in VC++ and as a standalone - both returned zero.
This is driving me nuts and I can't figure out why I'm getting different behaviour. Why is the standalone running differently, and what should I be looking at to fix this?
Thanks
Okay so it was literally a bug in my code that was very well hidden. I was dynamically casting to a wrong type.
Somehow it slipped past when I was running on Windows and OSX in both Debug and Release, and as a standalone on OSX. Good thing I found it.
Sorry about the short title, but I honestly can't get a better description of what is happening because I don't know enough...
Some background first, I am "converting" a multi-byte application to support unicode and I've made the standard char/string wchar_t/wstring changes and the my code is building without problems.
What happens is that when the application is being initialized it hits an assert when it registers the applications's document templates. The code is the standard
CMultiDocTemplate* pRepDocTemplate = NULL;
pRepDocTemplate = new CMultiDocTemplate(IDR_DIAGNOSTIC_REPORT_TYPE,
RUNTIME_CLASS(CDiagnosticReportDoc),
RUNTIME_CLASS(CChildFrame), // custom MDI child frame
RUNTIME_CLASS(CDiagnosticReportView));
and CDiagnosticsReportView has the standard DECLARE_DYNCREATE and IMPLEMENT_DYNCREATE in the header and source.
The assert is at doctmpl.cpp line 29 (mfc120ud.dll - at least is using the correct dll), but I can't find the source code anywhere to actually know what is happening.
The inheritance tree is pretty straightforward:
CDiagnosticReportView
\->CReportViewBase
\->CXTPReportView
\->CView
CXTPReportView is part of a framework that we are using which is provided by Codejock (Codejock extreme toolkitPro). From the build pane I know that it's linking against it's unicode debug dll (ToolkitPro1631vc120UD.dll)
Suffice to say that in the multibyte configuration this problem doesn't occur.
The project is configured to use the UNICODE character set (Project properties->Configuration Properties->General->Character Set).
Any help would be appreciated!
Thanks in advance!
It all had to do with the fact that I was linking against the non UNICODE build of Codejock. Even though I saw a reference to the UNICODE dll, the lib wasn't the correct one!
Problem was solved when I opened my eyes ;)
I'm trying to get the PCL Visualizer demo examples to work (all code here: http://pointclouds.org/documentation/tutorials/pcl_visualizer.php) for Windows, PCL 1.6, 32 bits version.
It works fine except for the Interaction Customization part, which is ironically the one i'm most interested on. An unhandled exception occurs at the spinOnce(100) line on the main method. From the long search I've done, it looks like it is deeply connected to VTK not being thread safe and keyboard/mouse callbacks interfering with the VTK window. However, I don't think I've completely understood this and could be mistaken. I have found a very similar question here in stackoverflow (using "pcl::visualization" in different threads from different instance of a class) and I tried using scoped_locks around the spinonce, as he suggests, but I think I'm not doing it right.
Has anyone managed to fully use this example on win32? For reference, here is my poor attempt at locking the spinonce:
while (!viewer->wasStopped ())
{
boost::mutex vis_mutex; //storage for static lock
boost::mutex::scoped_lock lock(vis_mutex);
viewer->spinOnce ();
boost::this_thread::sleep (boost::posix_time::microseconds (100000));
}
Thanks in advance!
I am afraid that it may be related to the version of PCL.
Tutorials are made to match latest versions of PCL and since 1.6 things might have changed.
I recommend you to update to the latest PCL from github. (actually I use code from this tutorial on win64 right out of the box, no issues)
I have a new project where I cannot use boost::format. I get a compiler error complaining that boost's override of a virtual function, ~basic_altstringbuf, lacks a "throw()". Even the most trivial attempt to use boost::format does that.
I have other projects where it works fine. I have verified that the new project uses the same include-paths for boost, and for the VC++ includes. All the projects have "Enable C++ Exceptions" set to Yes. The only explanation I can come up with is that the projects that work have some #DEFINE or some setting that disables those vile exception specs in the std:: include-files. But I have no idea what or where it might be. Any ideas?
Error 1 error C2694: 'boost::io::basic_altstringbuf::~basic_altstringbuf(void)': overriding virtual function has less restrictive exception specification than base class virtual member function 'std::basic_streambuf<_Elem,_Traits>::~basic_streambuf(void) throw()
EDIT: Corollary question: Is there a Properties-item in VS++ 2012 that will cause the std:: header files to be included without exception-specs? - short of turning off exceptions, that is?
At the request of the original owner of the green check-mark, I am submitting this summary.
The bugs are on the Microsoft side, in header-files for C++ standard library interfaces, and in the VC++ compiler when "Disable Language Extensions" is NOT set. The header files contain exception-specifications that the standard does not call for. When "language extensions" are not enabled, the compiler accepts invalid code. I have filed a bug report.
Boost could work around the problem in this specific case by adding seven characters to a nested include-file, i.e. "throw()" at line 65 in alt_sstream_impl.hpp. I filed a report with boost also, although I made it clear that the bug is not in their code. I am just suggesting a workaround.
All the tedious details are in the two reports linked above.
Check the preprocessor defines.
You might turn on and inspect verbose logging to see the exact flags that are passed to cl.exe
You could keep the preprocessed source and compare the version from the old (working) project with the new (failing) project.
My gut says, something else is being #defined/passed using -D in the old project that is not being defined in the new project, of differently (think of WINVER type macros)
See new answer posted: VC++ 2012 and Boost incompatibility - `throw()` specifications in library headers
EDIT by OP, Jive Dadson - It turned out to be /Za, which enables/disables "Microsoft language extensions." It is the contention of Visual Studio that the C++ standard requires that a program shall not compile if it has a virtual function override that is less restrictive in the "throw()" category than the function it overrides. Boost has a class that derives from basic_streambuf, and has a virtual destructor that lacks "throw()". The original destructor has that evil festoon. My new project will compile boost::format if I turn MS language extensions ON.
So the question becomes, who is wrong, and how? Is it standard-complying to put throw() on that destructor or not? Is the desired behavior (desired by me, that is) actually an "extension"? I seem to recall that MS considered some standard C++11 features to be "extensions," but I am not sure I remember correctly. Anyway, I will leave it to the boosters to decide, if they are interested. https://svn.boost.org/trac/boost/ticket/7477