There have been a number of examples posted to the web that demonstrate how to create a JSON array using boost's property tree.
The basic syntax is:
boost::property_tree::ptree array;
array.push_back(std::make_pair("", "value-1"));
array.push_back(std::make_pair("", "value-2"));
This appears to not work using boost 1.54 and visual studio c++ 2012. It works fine using VC 2010 and the same boost version.
The error I receive is "cannot convert parameter 1 from std::pair<_Ty1,_Ty2> to const std::pair<_Ty1,_Ty2> &"
Any suggestions that others may have on getting around this would be greatly appreciated.
ptree::push_back takes a ptree::value_type. Which is not a pair<key, value> but a pair<key, ptree>. push_back() forwards to insert() which copies the given ptree (defined with pair::second) into the current ptree
I would suggest sticking to ptree.add(). See the five minute tutorial, where it does essentially what you're wanting to do with an array of equally named nodes
Related
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
We build an OCX that contains a Map control and many supporting classes (e.g. GeoProjection, Extents) which can act as standalone classes and many of which are also Properties of the Map.
One of our legacy applications that uses the OCX is built in Visual Basic 6. After updating the build from VS2013 to VS2015, we noticed differences in how we have to access some of the properties from VB6. The two in particular that we had problems with were the Map.GeoProjection and the Map.Extents properties. They both started raising "Library Not Registered" errors when attempting to use them.
In the case of the GeoProjection, I was able to resolve the problem simply by adding the VB 'Set' command to the assignment, as follows:
Dim gp As New GeoProjection
gp.ImportFromEPSG m_MapProjection ' contains the EPSG code
Set Map.GeoProjection = gp.Clone
Why the 'Set' wasn't required before this, I don't know. It seems like it should have been since it is setting an object reference.
Even so, when I tried to do the same with the Extents property, it did not resolve the problem, but instead resulted in an "Automation Error". So I next went to review the IDL and MFC macro definitions to see how the definitions differed and why the behavior might differ.
The GeoProjection IDL
[id(192)] IGeoProjection* GeoProjection;
end the Extents IDL
[id(17), propput, nonbrowsable] void Extents(IExtents* nNewValue);
[id(17), propget, nonbrowsable] IExtents* Extents();
The GeoProjection dispatch macro
DISP_PROPERTY_EX_ID(CMapView, "Projection", dispidProjection, GetGeoProjection, SetGeoProjection, VT_DISPATCH)
and the Extents dispatch macro
DISP_PROPERTY_EX(CMapView, "Extents", GetExtents, SetExtents, VT_DISPATCH)
What particularly struck me was the difference in using the DISP_PROPERTY_EX vs the DISP_PROPERTY_EX_ID. Ironically, I can find no Microsoft Documentation on DISP_PROPERTY_EX_ID. The only guidance I could find were comments in the afxdisp.h file, where it describes the two groups of macros, as follows:
on line 288, prior to the macros without the _ID suffix
// these DISP_ macros cause the framework to generate the DISPID
and on line 313, prior to the _ID suffixed macros
// these DISP_ macros allow the app to determine the DISPID
Since we have an .h file that defines dispatch IDs for every function, it seems that we should always use those IDs within the macros, as follows. This assures that the Dispatch IDs will always be the same (which I think would matter when using early-bound COM calls).
DISP_PROPERTY_EX_ID(CMapView, "Extents", dispidExtents, GetExtents, SetExtents, VT_DISPATCH)
Once I made changes to the Extents property in the IDL
[id(17)] IExtents* Extents;
and in the use of the DISP_PROPERTY_EX_ID macro, we were able to successfully set the Extents property from VB6 using the 'Set' statement.
In summary, I don't really know
why the behavior changed in the first place (from VS2013 to VS2015)?
why my changes made things start working again (I have my theories)?
what is the recommended methodology going forward?
a. IDL syntax allows for property definition without having to specify propput and propget. Is one syntax recommended over the other?
b. should I change all of our macros to use the _ID suffixed macro?
Any insight is appreciated.
Thank you.
In new Visual Studio 2012 and 2013 forward declaration of functions gives "top-most" address to that function. They are not sequential anymore, if the one has prototype it will sit on top of memory space (as it is actually in source code - on top).
Code like this will not work as it suppose to:
int Offset = (VOID*)MAIN - (VOID*)FUNC1
How to prevent this, other then prototyping all functions? I hope there is some linker switch or Project settings.
I have found the problem.
Visual Studio 2012/2013 flag Project -> General ->
Whole Program Optimization : No Whole Program Optimization is used (in)correctly. With Use Link Time Code Generation TOP-DOWN compiling is archived regardless of how many forward declarations are there.
Someone more experianced should solve the mystery.
I'm having some real difficulties porting a really old Visual Studio 97 C++ project to Visual Studio 2010. Let me begin by first giving a little background on the errors I was getting immediately prior to this new LNK1224 error because they may be related, but I'm not sure.
Prior to my new error I was receiving this error:
error LNK2005: "void __cdecl operator delete(void *)" (??3#YAXPAX#Z) already defined in LIBCMT.lib(delete.obj) nafxcw.lib(afxmem.obj)
Through some digging I found that the reason for this error was because both the MFC and CRT libraries contain definitions for "new" and "delete" so they were colliding. Microsoft provides 2 solutions for this detailed in http://support.microsoft.com/kb/q148652/ . One of them was to make sure that in all your files you always include the MFC headers (afx stuff) first. Well there are about 100 files in this project and I just got tired of trying to find the files that were including resources in the wrong order. So I went with the other solution which is basically forcing libraries to load in a particular order. Basically you have to tell the compiler to ignore a particular library so that you can load it explicitly your self in the order that you choose. In my case, it was nafxcw.lib.
So under Project Properties --> Linker --> Input, I explicitly ignored nafxcw.lib and then explicitly included it at the front of the list.
So after doing this, my LNK2005 errors went away. But they were replaced with one single link error.
error LNK1224: invalid image base 0x287600000
I don't know if I fixed my previous link errors correctly and this new link error is in fact the next thing I have to deal with, or I simply created a more critical link error that is basically stopping the linking process before it gets to my original LNK2005 errors. In either case, there isn't much information I could find on this error. Microsoft doesn't say much in this link about it http://msdn.microsoft.com/en-us/library/3ya3f8wz%28v=vs.80%29.aspx
You specified an invalid base address for the image. Base addresses must be 64KB aligned (the last four hex digits must be zero) and image base must fit within a 32-bit signed or unsigned value.
This isn't all that helpful to me and there seems to be no other clues as to where this problem is coming from. I don't know what the next step is.
OK, so it looks like I have solved my own problem. Here is what I did. I needed to know where the heck this number was coming from so I simply used Notepad++ to do a word search through all the project files looking for "2876" which I got from the error message "LINK : fatal error LNK1224: invalid image base 0x287600000". I found that in the project file (.vcxproj) had the following entry in it:
<BaseAddress>0x287600000</BaseAddress>
So I opened it up and sat there wondering how this number was wrong. I mean I don't even know what this field is for. I didn't even generate this file, M$ made it. Why would the IDE create it's own input file incorrectly? Anyways, as I was trying to google this "BaseAddress" item to figure out what it was, it dawned on me that it looked like there were too many zero's. So I went back and counted and sure enough, this wasn't a 32-bit number, it was a 36-bit number. Deleted one of the zero's, recompiled, and boom it worked. Low and behold, that's kind of what the defintion I looked up, mentioned in the problem statement, hinted at looked up earlier on MSDN but it didn't click.
I don't make a habit to rummage through auto generated files very often so I never questioned that this may be the problem.
I have a map file generated with microsoft visual studio. It contains a relatively big area named __NULL_IMPORT_DESCRIPTOR. What is this good for? It has something to do with linked dlls but I cannot figure out the exact purpose of it.
__NULL_IMPORT_DESCRIPTOR is the IMAGE_IMPORT_DESCRIPTOR structure. With all its fields set to null it indicates the end of the IMAGE_IMPORT_DESCRIPTOR array in the imports section. It takes only 20 bytes.