Библиотека MFC и среда разработки MS Visual Studio обеспечивают разработчику выбор средств, позволяющих ввести в MFC-приложение такие элементы пользовательского интерфейса как, например, меню, toolbars, диалоговые панели. В том числе, обеспечивается и возможность ввести эти элементы в ресурсы приложения и, по мере необходимости, загружать их в память оттуда. Насколько я могу судить для случая Windows Forms-приложения (WFApp - сокращение мое), библиотека классов FCL и инструментарий MS Visual Studio .NET не имеют собственных прямых средств для организации этих UI-элементов именно на базе ресурсов приложения. Конечно, это не представляется принципиально трудной задачей, и можно, например, привлечь для решения ее средства Win32 API или использовать в таком приложении и библиотеку MFC. Или, в конце концов, вообще не использовать ресурсы приложения. Но хотелось бы получить информацию и советы от опытных программистов о том, (i) как для WFApp они организуют свой пользовательский интерфейс на базе ресурсов, включая и подключение обработчиков сообщений (команд). То есть, каковы здесь стандартные приемы и культура программирования? Заодно хотелось бы узнать, (ii) как в таком же приложении (то есть, WFApp) рационально подключить функцию-член какого-либо класса к требующемуся сообщению Windows (а не к событию, определенному для FCL-класса).
Спасибо!

Извините, последний вопрос не совсем точно сформулировал. Имеется в виду:
Как во Windows Forms-приложении подключить функцию-член какого-либо класса (а вообще-то, и просто функцию) к сообщению Windows (а не к событию, определенному в FCL-классе), в качестве обработчика этого сообщения?

Простите, а зачем?
Я, конечно, понимаю - это не ответ на вопрос (сейчас пытаюсь найти ответ..), но все-таки?..

Цитата(Valentin @ 3.5.2004, 19:03)

Извините, последний вопрос не совсем точно сформулировал. Имеется в виду: Как во Windows Forms-приложении подключить функцию-член какого-либо класса (а вообще-то, и просто функцию) к сообщению Windows (а не к событию, определенному в FCL-классе), в качестве обработчика этого сообщения?

Аааа... Кажется, понял..
Посмотри в сторону класса NativeWindow.
Я с таким пока сильно не работал, так самую малость. Фактически ты будешь создавать native-объект, к-й GC просто так не уберет..
Короче, вот - отыскал тебе примерчик, тут показано как со всем этим работать:

Код

using System; using System.Drawing; using System.Windows.Forms; using System.Runtime.InteropServices; namespace NativeWindowApplication {    // Summary description for Form1.    public class Form1 : System.Windows.Forms.Form    {        private MyNativeWindowListener nwl;        private MyNativeWindow nw;        internal void ApplicationActived(bool ApplicationActivated){            // The application has been activated or deactivated            System.Diagnostics.Debug.WriteLine("Application Active = " + ApplicationActivated.ToString());        }        public Form1()        {            this.Size = new System.Drawing.Size(300,300);            this.Text = "Form1";            nwl = new MyNativeWindowListener(this);            nw = new MyNativeWindow(this);                    }        // The main entry point for the application.        [STAThread]        static void Main()        {            Application.Run(new Form1());        }    }    // NativeWindow class to listen to operating system messages.    public class MyNativeWindowListener: NativeWindow{        // Constant value was found in the "windows.h" header file.        private const int WM_ACTIVATEAPP = 0x001C;        private Form1 parent;        public MyNativeWindowListener(Form1 parent){            parent.HandleCreated += new EventHandler(this.OnHandleCreated);            parent.HandleDestroyed+= new EventHandler(this.OnHandleDestroyed);            this.parent = parent;        }        // Listen for the control's window creation and then hook into it.        internal void OnHandleCreated(object sender, EventArgs e){            // Window is now created, assign handle to NativeWindow.            AssignHandle(((Form1)sender).Handle);        }        internal void OnHandleDestroyed(object sender, EventArgs e) {            // Window was destroyed, release hook.            ReleaseHandle();        }    [System.Security.Permissions.PermissionSet(System.Security.Permissions.SecurityAction.Demand, Name="FullTrust")]        protected override void WndProc(ref Message m){            // Listen for operating system messages            switch (m.Msg){                case WM_ACTIVATEAPP:                    // Notify the form that this message was received.                    // Application is activated or deactivated,                    // based upon the WParam parameter.                    parent.ApplicationActived(((int)m.WParam != 0));                    break;                            }            base.WndProc(ref m);        }            }    // MyNativeWindow class to create a window given a class name.    public class MyNativeWindow: NativeWindow{        // Constant values were found in the "windows.h" header file.        private const int WS_CHILD = 0x40000000,                          WS_VISIBLE = 0x10000000,                          WM_ACTIVATEAPP = 0x001C;                private int windowHandle;        public MyNativeWindow(Form parent){            CreateParams cp = new CreateParams();            // Fill in the CreateParams details.            cp.Caption = "Click here";            cp.ClassName = "Button";                        // Set the position on the form            cp.X = 100;            cp.Y = 100;            cp.Height = 100;            cp.Width = 100;            // Specify the form as the parent.            cp.Parent = parent.Handle;                        // Create as a child of the specified parent            cp.Style = WS_CHILD | WS_VISIBLE;            // Create the actual window            this.CreateHandle(cp);        }        // Listen to when the handle changes to keep the variable in sync        [System.Security.Permissions.PermissionSet(System.Security.Permissions.SecurityAction.Demand, Name="FullTrust")]        protected override void OnHandleChange(){            windowHandle  = (int)this.Handle;        }    [System.Security.Permissions.PermissionSet(System.Security.Permissions.SecurityAction.Demand, Name="FullTrust")]        protected override void WndProc(ref Message m){            // Listen for messages that are sent to the button window. Some messages are sent            // to the parent window instead of the button's window.            switch (m.Msg){                case WM_ACTIVATEAPP:                    // Do something here in response to messages                    break;            }            base.WndProc(ref m);        }          } }

ИМХО, разработчики сделали ВСЕ от них зависящее, чтоб простой народ как можно реже применял обработчики сообщений окна
Тебе это надо было? Угадал?..

Уважаемый Kurt!
Большое спасибо Вам за внимание к моим вопросам и Ваш исчерпывающий ответ. Фактически, он отвечает на оба мои вопроса, так как, для меня, они связаны между собой. По моим рабоче-крестьянским соображениям новичка в .NET, можно, вероятно, для подключения обработчиков сообщений Windows использовать также и метод Form::PreProcessMessage, хотя я не проверял еще это. Но применение указанной Вами методики является, безусловно, более логичным и, как мне кажется, более универсальным.

Что касается Вашего вопроса, зачем мне это нужно, то, например, мне так легче обеспечить без перепрограммирования приложений поддержку многоязычности пользовательского интерфейса и переключения языков. Вводишь в приложение новые языковые ресурсы в любом количестве и добавляешь программный код, определяющий их количество и осуществляющий их выборку в память приложения. Для .NET платформы такая схема особенно упрощается, учитывая концепцию сборок (assembly). Что касается вопроса о подключении обработчиков сообщений Windows, то, надеюсь, это мне позволит более квалифицированно решать задачи низкоуровнего программирования, с которыми мне ранее (до знакомства с .NET) приходилось сталкиваться. Вообще говоря, заданные мной вопросы возникли после беглого освоения мной основ программирования для платформы .NET. Я перебирал в памяти разные приемы, которые использовал ранее при разработке программ в MS Visual C++, и задумался над тем, все ли я смогу реализовать программно для .NET, из того, что делал ранее и из того, что надо бы уметь делать. Конечно, .NET платформа многие моменты исключает. Но многие все же остаются.

Буду рад быть полезным и Вам, если смогу.
С Уважением, Валентин
Рига
[email protected]

Я Вас понимаю..
Хотя, все-таки, мне кажется, используя .NET стоит избегать таких извращений.(обработка native-сообщений..)
Вобщем, всегда рад помочь.
Заходите!