Можно «закрутить» несколько GUI потоков? (Не останавливая систему в Application.Run)

голоса
20

Моя цель

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

Задний план

У меня есть система на основе компонента , в котором контроллер динамически загружать сборки и инициализирует и запускать классы , реализующие общий IComponentинтерфейс с одним методом DoStuff().

Какие компоненты , которая загружается конфигурируется с помощью файла конфигурации XML и путем добавления новых узлов , содержащих различные реализации IComponent. Компоненты обеспечивают сервисные функции к основному приложению. В то время как основная программа делает это дело, например , контролировать атомную станцию, компоненты могут выполнять служебные задачи (в своих собственных потоках), например , очисткой базы данных, отправка электронной почты, печати смешных шуток на принтере, что там у вас. То , что я хотел бы , чтобы иметь один из этих компонентов будет способен отображать графический интерфейс, например , с информацией о состоянии указанной электронной отправки компонента.

Срок службы всей системы выглядит следующим образом

  1. начинается применение.
  2. Проверьте файл конфигурации компонентов для загрузки. Загрузите их.
  3. Для каждого компонента, запустите DoStuff()его инициализацию и сделать его жить свою жизнь в своих собственных потоках.
  4. Продолжайте делать главное приложение-штуковина король работы, навсегда.

Я до сих пор не удалось успешно выполнить пункт 3 , если компонент запускает графический интерфейс пользователя в DoStuff(). Это просто просто останавливается , пока GUI не будет закрыт. И не до тех пор , пока GUI закрыто делает ход выполнения программы в пункте 4.

Было бы замечательно, если бы эти компоненты позволили запустить ГПИ свой собственный Windows Forms.

проблема

Когда компонент пытается запустить графический интерфейс в DoStuff()(точная строка кода при запуске компонента Application.Run(theForm)), компонент и , следовательно , наша система «зависает» на Application.Run()линии , пока GUI не будет закрыт. Ну, просто загорелся GUI работает отлично, как и ожидалось.

Пример компонентов. Никто не имеет ничего общего с графическим интерфейсом, в то время как вторые костры вверх милые окнами с розовыми пушистыми кроликами в них.

public class MyComponent1: IComponent
{
    public string DoStuff(...) { // write something to the database  }
}

public class MyComponent2: IComponent
{
    public void DoStuff()
    {
        Application.EnableVisualStyles();
        Application.SetCompatibleTextRenderingDefault(false);
        Application.Run(new Form());

        // I want the thread to immediately return after the GUI 
        // is fired up, so that my main thread can continue to work.
    }
}

Я попытался это не повезло. Даже когда я пытаюсь запустить графический интерфейс в его собственном потоке, выполнение не останавливается, пока GUI закрытым.

public void DoStuff()
{
    new Thread(ThreadedInitialize).Start()
}

private void ThreadedInitialize()
{
    Application.EnableVisualStyles();
    Application.SetCompatibleTextRenderingDefault(false);
    Application.Run(new Form());
}

Можно ли закрутить графический интерфейс и вернуться после того, как Application.Run()?

Задан 05/08/2008 в 22:19
источник пользователем
На других языках...                            


3 ответов

голоса
11

Application.Run метод отображает один (или более) форму и инициирует стандартный цикл обработки сообщений , который работает до тех пор , все формы не будут закрыты. Вы не можете заставить вернуться из этого метода , за исключением, закрыв все формы или заставляя завершение приложения.

Вы можете, однако, передать ApplicationContext (вместо внесения новой формы ()) к методу Application.Run и ApplicationContext может быть использован для запуска нескольких форм сразу. Приложение закончится только тогда , когда все те закрыты. Смотрите здесь: http://msdn.microsoft.com/en-us/library/system.windows.forms.application.run.aspx

Кроме того, любые формы, которые вы показываете покадрово будет продолжать работать вместе с вашей основной формой, которая позволит вам иметь более одного окна, которые не блокируют друг друга. Я считаю, что это на самом деле то, что вы пытаетесь достичь.

Ответил 05/08/2008 d 22:45
источник пользователем

голоса
0

Я не уверен, если это правильно, но я помню, как работаю окно формы из консольного приложения, просто newing формы и вызов newForm.Show () на нем, если ваши компоненты используют, что вместо Application.Run (), то новый форма не должна блокировать.

Конечно, компонент будет отвечать за поддержание ссылки на формы, которые она создает

Ответил 23/05/2009 d 22:57
источник пользователем

голоса
0

Я уверен, что это возможно, если вы взломать на него достаточно сложно, но я хотел бы предложить, это не очень хорошая идея.

«Windows» (что вы видите на экране) высоко в сочетании с процессами. То есть, каждый процесс, который отображает все GUI, как ожидается, иметь цикл обработки сообщений, который обрабатывает все сообщения, которые участвуют в создании и управления окнами (такие вещи, как «нажали на кнопку», «закрыли приложение», «перерисовки экрана ' и так далее.

Из-за этого, он более или менее предполагается, что если у вас есть какие-либо цикл обработки сообщений, он должен быть доступен в течение всей жизни процесса. Например окно может отправить вам «бросить курить» сообщение, и вы должны иметь цикл обработки сообщений доступного для обработки, что, даже если вы не получили ничего на экране.

Лучше всего это сделать так:

Сделать поддельную форму, которая никогда не отображается который является вашим «основным приложением» Start Up Call Application.Run и передать в этой поддельной форме. Сделайте свою работу в другом потоке, и огонь событий в главном потоке, когда вам нужно сделать Gui вещи.

Ответил 06/08/2008 d 00:22
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more