Обнаружена проблема при преобразовании инструмента из VC ++ 6.0 в VS2013. Ошибка не является действительной ошибкой в коде, так как код компилируется без «ошибок» и работает просто отлично. Программа была откорректирована минимально, практически без изменений в коде, чтобы позволить программе правильно работать и работать в VS2013, или так я думал. Когда мы протестировали код для чтения с внешнего запоминающего устройства, на левой панели приложения отображалось дерево RichText, которое, казалось, работало или функционировало с тем, что, как казалось, представляло собой все имеющиеся данные, но с Rich Text мы так привыкли к визуальное зрение отсутствовало в правой панели основного приложения. Меня заинтересовал тот факт, что в исходной программе вы не могли редактировать текст, но в нашей новейшей скомпилированной программе вы могли видеть, что область не изменилась по сравнению с исходным состоянием. Почти как если бы эти данные попадали в приложение, но по какой-то странной причине их удаляли или удаляли прямо перед отображением на панели.
Так вот в чем проблема, когда WCARichEdit.cpp делает это
«
EDITSTREAM es;
es.dwError=0;
es.dwCookie = (DWORD) &Report;
es.pfnCallback = CBStreamIn;
lStreamReturn = GetRichEditCtrl().StreamIn(SF_RTF, es);
GetRichEditCtrl().SetReadOnly(TRUE);
«
Он ломает или выдает ошибку 0, если SF_RTF не изменен на SF_TEXT. Затем код генерирует все данные, но форматирование считывается в поток текста. Один гигантский поток, который есть. Мы полагаем, что форматирование в этом коде является виновником того, почему текст не отображается, когда мы компилируем наш код. Поэтому, когда SplitterFrame.CPP делает это
«
Void CSplitterFrame::DisplayReport(CString Report)
{
CWcaRichEdit*RichEditView = (CWcaRichEdit*) m_wndSplitter.GetPane(0,1);
CH1_MainteanceToolDoc*pDoc = (CH1_MainteanceToolDoc*)
((CMainFrame *)AfxGetMainWnd())->GetActiveDocument();
RichEditView->DisplayReport(pDoc, Report);
}
«RichEditView-> DisplayReport (pDoc, Report), похоже, не получает никакого кода, поскольку он просто обнуляется. Это подтверждается dwError = 0, не показывающим изменений, когда SF_RTF остается неизменным.
Есть мысли о том, как получить этот Rich Text для отображения?
Во время устранения неполадок этот код ниже был написан для передачи строки в текстовый файл.
#if
DWORD dwError;
CFile testfile;
if (0 == testfile.Open ("C:\\...rtftestfile.txt", CFile::modeCreate | CFile:modeWrite | CFile::shareDenyNone))
{
dwError = GetLastError();
{
testfile.Write((LPCTSTR) Report, Report.GetLength());
testfile.Close();
#endif
Файл был создан успешно, и по какой-то причине было принято решение сохранить файл после открытия файла .text в WordPad. Затем мы сохранили файл как новое расширение .rtf. Как ни странно, программа не просмотрела все наше форматирование, а добавила некоторый код в микс, так как размер файла wordpad и текстового файла варьировался по размеру. Затем мы взяли каждый файл и «перетаскивали его» в программу блокнота для дальнейшего просмотра. Как ни странно, «\ rtf1» был добавлен в начало нашей гигантской строки. Странно, зачем WordPad добавить это … подождите. Пришло осознание, и мы вернулись и изменили наш код
const char RTF_Header[] = "{\\ansi\\ansicpg1252\\deff0\\deflang1033{\\fontbl{\\f0\\fnil\\fcharset0 Courier New;}}\\viewkind4\\uc1\\pard\\fs17 ";
в
const char RTF_Header[] = "{\\rtf1\\ansi\\ansicpg1252\\deff0\\deflang1033{\\fontbl{\\f0\\fnil\\fcharset0 Courier New;}}\\viewkind4\\uc1\\pard\\fs17 ";
Учебный момент заключается в том, что если вы знаете, что ваше форматирование нарушает ваш код, напечатайте эту гигантскую строку в файл, чтобы увидеть, что она делает, и вставьте ее во что-то, что поместит форматирование rtf там, где оно отсутствует.
Другой вариант — иметь под рукой кого-то, кто любит использовать потрясающую силу Rich Text и может запомнить все способы его форматирования.
Также здесь есть обсуждение на форуме Microsoft, если вы хотите отважиться на это:
Форум Microsoft GetRichEditCtrl (). StreamIn ломается при форматировании
Других решений пока нет …