Hi,

So I found that if I detect the borqued schema number at the point is serialises the runtime class, I can tweak that back to the correct version and then serialise without error. Everything works great. However this is not a good fix because it would inevitably break if someone had the old schema version and serialised it with my new code. 

{

if (!OnBeforeExchange())

return FALSE;

if (!IsLoading())

{

m_ar.WriteClass(pClass);

}

else

{

pClass = m_ar.ReadClass(pDefaultClass, &m_nSchema);

if (m_nSchema == 37)

m_nSchema = _XTP_SCHEMA_CURRENT;

if (!pClass)

return FALSE;

}

return TRUE;

}

Q: How and Why is the schema ending up as a 'hardcoded' 37 when from my debugging _XTP_SCHEMA_CURRENT and those controls m_nSchema  is 40 when the objects are saved to the archive?

So I think I found out why this http://forum.codejock.com/forum_posts.asp?TID=21649&title=cxtpcontrol-causing-carchiveexception

Is blowing up, so the control that is serialised to the registry when being loaded back in still has

_XTP_SCHEMA_1340

instead of my new schema

_XTP_SCHEMA_1350

even thought 

#define _XTP_SCHEMA_CURRENT _XTP_SCHEMA_1350

So I decided to do some digging I changed the actual value for 

#define _XTP_SCHEMA_1340 (0x25)

to 

#define _XTP_SCHEMA_1340 (0x27)

and my new define to 

however on loading the control back from the registry it still = 37 even though I changed the old 

#define _XTP_SCHEMA_1340 (0x25) to be 39 

What have I missed? why is the schema value not the new schema number when I load from the registry? What is changing it?

If I ignore the schema being wrong or hard code it back to my correct schema number it serialises my new data value correctly and doesnt throw any issues.

Looks like there is a hard coded issue somewhere?

Any help?