Click here to Skip to main content
15,346,923 members

Comments by hairy_hats (Top 35 by date)

hairy_hats 15-Feb-17 6:02am View
   
The simplest way seems to be to compare the requested file save path with the auto-save path in OnSaveDocument and set a manual/auto-save flag appropriately before saving the file:

BOOL CMyDoc::OnSaveDocument(LPCTSTR lpszPathName) 
{
	CDataRecoveryHandler* autohandler = AfxGetApp()->GetDataRecoveryHandler();
	CString autosavepath = autohandler->GetAutosavePath();
	BOOL success = FALSE;

	if (CString(lpszPathName).Left(autosavepath.GetLength()).CompareNoCase(autosavepath) == 0)
	{
		// autosaving - just call the default
		m_manualSave = false;

		success = CDocument::OnSaveDocument(lpszPathName);
	}
	else
	{
		// manual save - do whatever is needed
		m_manualSave = true;

		success = CDocument::OnSaveDocument(lpszPathName);
	}
	
	return success;
}
hairy_hats 30-Nov-16 7:35am View
   
For Arduino-specific problems you might be better off asking on the Arduino forums.
hairy_hats 29-Nov-16 11:30am View
   
The mystery deepens. I've moved the classes back into the EXE and the problem persists: the first object to be deserialized is fine, but the second is mis-interpreted by the schema lookup code.
hairy_hats 29-Nov-16 7:47am View
   
Suppose you had:

char [] hello = "Hello, world!";

CString string(hello); // string contains "Hello, World!"

strcpy(hello, "Goodbye!");

If you use cstr=str; then string now contains "Goodbye!" even though you changed hello. If you allocate your own memory and copy the initialisation text, then your class's internal text doesn't change.
hairy_hats 29-Nov-16 6:12am View
   
Please can you explain further why I need to override the >> operator when the first object loads correctly using the >> operator? Thanks!

Also, doesn't CodeProject contain many classes which derive from MFC classes in DLLs?!
hairy_hats 1-Oct-15 11:38am View
   
I was hoping to avoid too much new coding, but that may be the best way.

It's pretty dire that MS have decided to obsolete it without providing an easy upgrade solution along those lines!
hairy_hats 25-Oct-13 6:56am View
   
Have you tried deleting the corresponding Registry data for your program? Sometimes changes to the UI don't show up if you change something without deleting the Registry data, as Maximilien said above.
hairy_hats 8-Feb-13 11:00am View
   
One of the big problems with moving data out of the existing CDocument into its own separate structure is file compatibility - MFC Serialization makes it tricky to make large-scale changes or move classes into namespaces etc.
hairy_hats 8-Feb-13 4:39am View
   
I think that is a good idea - do a first pass to get the code better-organised and separated, and then worry about the UI afterwards.
hairy_hats 8-Feb-13 4:16am View
   
I don't think anyone was suggesting rewriting the entire code base.
hairy_hats 7-Feb-13 11:03am View
   
Thanks, guys - I thought that was probably what would be suggested! Extracting the data from the CDocument class into a standalone data structure will be a pain but it does need doing for easier future maintainability.

I will roll up my sleeves and tell them to be patient... :D
hairy_hats 20-Jun-12 10:58am View
   
That's got it! Thanks Eugen! :D
hairy_hats 20-Jun-12 10:48am View
   
That's what I do, but with a derived button, as described here. If I get a pointer to this replaced button via CMFCToolBar::GetCommandButtons(), I get a pointer to a CMFCToolBarComboBoxButton, not to my derived class. I deleted the Registry entries so that they were regenerated with the new class.
hairy_hats 23-Apr-12 14:19pm View
   
You're definitely not that! Thanks anyway. :)
hairy_hats 23-Apr-12 13:57pm View
   
I used SA during my PhD - I was hoping for something more deterministic.
hairy_hats 26-Jan-12 10:41am View
   
Deleted
It might be because the link order affects the order in which the DLLs are initialised, and the mixed-mode DLLs have to be initialised first, but I don't know for certain if that is the reason.
hairy_hats 9-Jan-12 12:06pm View
   
mbstowcs_s returns the number of characters that were converted, *including* the null terminator. My mistake was in passing that length to Graphics::DrawString, but as I said before, Windows 7 rendered it correctly.
hairy_hats 9-Jan-12 8:35am View
   
Problem solved! Windows 7 ignores the string's zero terminator (or at least, renders it invisibly), but XP renders it as a square box. Reducing the string length passed to the rendering function by one fixed it.
hairy_hats 9-Jan-12 7:48am View
   
I have just checked once again to make sure, and as I said, the text strings sent to the Graphics object are identical (zero-terminated wchar_t strings).
hairy_hats 9-Jan-12 7:47am View
   
Deleted
I have just checked once again to make sure, and as I said, the text strings sent to the Graphics object are identical (zero-terminated wchar_t strings).
hairy_hats 9-Jan-12 6:09am View
   
The same text strings worked fine with GDI under XP Mode, and they work fine under Windows 7 using GDI+, so I don't think that is the problem. I suspect it's something to do with GDI+ and XP.
hairy_hats 19-Dec-11 16:47pm View
   
I've spent 3 solid days trying to find out what was causing it! What was very slow was verifying and reloading the docked bar status. Without them it is much quicker-it was nothing to do with DLLs loading as it was slow every time. Anyway, it is working now so I will keep testing it.
hairy_hats 16-Dec-11 17:25pm View
   
The run command argument can be /dde, in which case the program starts and waits for a DDE open command to load the file, instead of passing the filename. This is one easy way you can load multiple files into one MDI. I think the problem I have encountered could be due to my InitInstance taking too long to load, and the OS claiming there is a problem, when really the program is just not ready to accept the DDE command. I am going to try to restructure the code on Monday to see if that helps.
hairy_hats 16-Dec-11 17:25pm View
   
Deleted
The run command argument can be /dde, in which case the program starts and waits for a DDE open command to load the file, instead of passing the filename. This is one easy way you can load multiple files into one MDI. I think the problem I have encountered could be due to my InitInstance taking too long to load, and the OS claiming there is a problem, when really the program is just not ready to accept the DDE command. I am going to try to restructure the code on Monday to see if that helps.
hairy_hats 16-Dec-11 10:57am View
   
OK, so the problem is that the DDE Open command isn't being received following the first double-click, but it is with the second. Does that help narrow it down?
hairy_hats 16-Dec-11 9:38am View
   
The default command line arguments are the same in both cases, so I don't think it's that. I'll try to dump the parameters - thanks for the suggestion!
hairy_hats 18-Mar-11 10:01am View
   
You win for simplicity, John.
hairy_hats 18-Mar-11 6:42am View
   
This method still involves doing a check on which class is instantiated at every method call {a ? a->M(); : b->M();} so effectively does the same as JSOP's original solution. If I have to do a comparison at every call, there isn't much to be gained and I might as well leave the code as it is.
hairy_hats 17-Mar-11 16:48pm View
   
I would if it wasn't for MFC Serialization, which doesn't appreciate changing the derivation of the classes it is trying to load.
hairy_hats 17-Mar-11 16:42pm View
   
No, the type is known. pClassA is always of type ClassA and pClassB is always of type ClassB, but only one of them will be allocated.
hairy_hats 17-Mar-11 12:17pm View
   
Yes, so every time it calls one of the functions it has to check which one is instantiated.
hairy_hats 17-Mar-11 12:05pm View
   
You can't get away from the if statement completely, but it could be possible to just do it once at the top of the program where a table would be set up. It wouldn't then be necessary to do it every time, just call the bound functions directly. It could be that the most efficient way would be to only bother binding the most commonly-used functions, and do a single function like the one you proposed for the rarer ones.
hairy_hats 17-Mar-11 12:04pm View
   
Deleted
You can't get away from the if statement completely, but it could be possible to just do it once at the top of the program where a table would be set up. It wouldn't then be necessary to do it every time, just call the bound functions directly. It could be that the most efficient way would be to only bother binding the most commonly-used functions, and do a single function like the one you proposed for the rarer ones.
hairy_hats 17-Mar-11 11:43am View
   
I'm not trying to call B's methods from A. As I said above, the code only instantiates one or the other. I am just looking for methods that allow me not to have to check if pClassA or pClassB have been allocated before each and every function call.
hairy_hats 17-Mar-11 10:33am View
   
It's a possibility, but I'm hoping to find a way which avoids having to do the comparison every time. I'm looking at Boost.Function as a possible way of setting up a table of pointers to functions at the top of the program, so no comparison needs to be made at the point of calling, but it's crude in comparison to polymorphism.