Comments by hairy_hats

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.

Comments by hairy_hats (Top 35 by date)