Помогите пожалуйста разобраться. Я уже ничего не понимаю.
1. Есть приложение написано на VC++ для MFC с использованием AppWizard
там она создает класс что то типа CProgaApp theApp и делает его глобальным. Но почему то я не могу к нему достучаться из какойлибо функции CProgaDlg.. :(
2 .как в принципе сделать глобальную переменную?
3. допустим класс CFirst
class CFirst {
public:
//...
CSecond A;
//...
};
class CSecond {
func();
};
CSecond::func() {/*кaк отсюда обратиться к какой-либо переменной или функции из CFirst?*/ };
> 3. допустим класс CFirst > class CFirst { > public: > //... > CSecond A; > //... > }; > class CSecond { > func(); > }; > CSecond::func() {/*кaк отсюда обратиться к какой-либо > переменной или функции из CFirst?*/ }; поробуй func() сделать френдовской для CFirst. Сам я ИМЕННО так не делал, но думаю может прокатить ИМЕННО в этом примере ;)
>
> возможно я сильно глючу возможно я тоже
[Win32] советую разобраться с моделью приложения,принятой в mfc,а так же с архитектурой document/view12.08.02 18:15 Автор: beetle <beetle> Статус: Member
юзай AfxGetApp() для полученя указателя на класс приложения
в твоем случае енто класс CProgaApp
в основном при отображении работа идет в классах C*View
для получения указателя на класс документа юзай GetDocument()
в АppWizard я сделал Dialog-Based...поэтому у меня просто нету CProgaView12.08.02 19:08 Автор: vh <Дмитрий> Статус: Member
Dialog base project содержит только две заготовки по дефолту:
CYourNameApp - стандартный класс каркаса приложения
CYourNameDlg - непосредственно клас диалога
для получения указателя на екземпляр класса приложения из класса диалога CYourNameDlg делается след:
CYourNameApp* pApp = AfxGetApp();
и юзай себе все, что душе угодно и где угодно
для доступа к объекту диалога следует:
создать в классе CYourNameApp атрибут-указатель на класс твоего диалога
и потом проинициализировать его непосредственно при создании диалога - в функции InitInstanse:
OOL CPhMngrApp::InitInstance()
{
// Standard initialization
// If you are not using these features and wish to reduce the size
// of your final executable, you should remove from the following
// the specific initialization routines you do not need.
#ifdef _AFXDLL
Enable3dControls(); // Call this when using MFC in a shared DLL
#else
Enable3dControlsStatic(); // Call this when linking to MFC statically
#endif
CPhMngrDlg dlg;//вот тут и инициализируй свой поинтер на диалог
m_pMainWnd = &dlg;
int nResponse = dlg.DoModal();
if (nResponse == IDOK)
{
// TODO: Place code here to handle when the dialog is
// dismissed with OK
}
else if (nResponse == IDCANCEL)
{
// TODO: Place code here to handle when the dialog is
// dismissed with Cancel
}
// Since the dialog has been closed, return FALSE so that we exit the
// application, rather than start the application's message pump.
return FALSE;
}
[C++] Гон! Смотри, в чем дело:13.08.02 04:15 Автор: Zef <Alloo Zef> Статус: Elderman
> VC каждый класс пишет в своем cpp-файле. Чтобы увидеть > переменную, объявленную в хедере приложения, нужно ее в > этих файлах объявить, как external.
Бла бла бла... А MS такие дураки сидят, не могли экстерналом переменную обявить, да ?
Человек правильно написал AfxGetApp() и никаких извращений. То что ты предложил - в принципе верно, но с mfc я бы не рекомендовал делать шаги вправо, влево. Не переносит mfc этого.
[C++] Не знаю, я сразу нашел этот способ, он работает, а в других мне нужды нет...14.08.02 04:59 Автор: Zef <Alloo Zef> Статус: Elderman Отредактировано 14.08.02 05:26 Количество правок: 2
А что до мфсей, то если не лень, я их целиком никогда не юзаю. Там всяких проверок ненужных целый вагон, например он волочит за собой куски ОЛЕ, даже если всеми "законными" средствами ему это запрещаешь. Так, что я выдираю только те куски, которые используюся моей прогой, обрубаю все тесты, кроме самых нужных, неиспользуемые кейзы и условные переходы. Конечно, если пишешь MDI-ную прогу с крутым интерфейсом, то это непосильный труд, Но для диалог-базед утилти в самый раз, тем более, что VC не Борланд, он визуальное конструирование почти не автоматизирует и все контролы приходится прогать вручную.
Ну, а в Мелкософте, действительно, не дураки они специально "слегка" путают код и пропускают в хелпах ключевые моменты (см. мой пост про компиляцию драйверов), чтобы не ковыряясь, сходу мог что-то делать только тот, кто прошел ихние курсы и ему показали "на пальцах" всю цепочку необходимых операций, ничего не объясняя. Кроме того, это защищает их от всяких "внеплановых" подходов.
Кто-нить пробовал компилить MFC из сырцов? Хрен получится! Хотя дебагер их "видит" правильно. А, чтобы их перекомпилить, и настройки компилера надо менять и, похоже, не все инклюды в сырцах прописаны...
[C++] тогда лучше использовать namespases - с external linker может ругаться - видимо у него так и произошло13.08.02 05:47 Автор: beetle <beetle> Статус: Member
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
