Всё понятно. Класс называется TForm1, а экземпляр - Form1. Переменная экземпляра формы, наверно, даже где-то объявлена , поэтому можно к ней обращаться из кода. Всё, что заполняется в дизайнере и Properties-ах, автоматом кладётся в исходник и ресурсы, насколько мне помнится из общения с делфями.

В WinForms похожий подход, дизайнером тоже создаётся специальный метод InitializeComponent, в который кладётся всё, что мы дизайним и настраиваем в Properties. Вот только экземпляр типа Form1 не создаётся автоматически - мы должны позаботиться об этом сами, т.к. изначально есть возможность создать много экземпляров одного класса (TForm1). К примеру, главная форма приложения создаётся в методе Main():


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

З.Ы. можно в принципе замутить статик-переменную с экземпляром формы, заполнять её в конструкторе формы, и тогда вполне можно обратиться к формам так (при условии, что указанная форма существует в данный момент времени):

или так:


НО однозначно более правильным способом остаётся передача экземпляра одной формы в конструктор другой.

Все предельно просто.
создаем в классе формы указатель на "родительскую" форму

public class ChildForm
{
        private ParentForm parentForm;
        ///ctor
         public child(ParentForm link)
        {
              this.parentForm=link;
        }
 .................
}

вот и все...
теперь создаем э.ф.

...
{
       ChildForm childForm=new ChildForm(this);
       childForm.Show();
}

и соответственно обращаемся к родителю просто 
parentForm. ....;

3me1, это то о чём неоднократно говорилось:   

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

kobra, есть принцип ООП -- инкапсуляция называется. Звучит он примерно так: Никакие данные внутри класса изменять нельзя. Можно только попросить класс изменить что-то, и если эти изменения согласуются с внутренней политикой класса, то он их сделает.
Определение, конечно, бестолковое, но суть проясняет 
Например тебе в классе формы хочется, чтобы в ее заголовке отображалось содержимое некоторого текстБокса. Если теперь напрямую поменять значение текстбокса, то не факт что форма его подхватит.
Конечно можно подписаться на событие смены текста в текстбоксе. Но это только пример    

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

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

Но с другой стороны. Принципы ООП, ИМХО, жестко относятся только к повторно используемому коду. Если ты точно знаешь, что твоим классом никто не воспользуется (например кому нужна форма с конретным положением конкретных элементов на ней), то на ООП можно забить  

99% всех форм, которые я делаю, мне нужны не как клас, а как один егземпляр (ну не совсем правилно выразился но надеюс поимете), так что
я о том же   

сорри  я завтыкал 

M mr.DUDA

Тема закреплена. Все аналогичные вопросы будут перенаправляться в эту тему, с автоматическим закрытием исходной темы.

При открытии понятно.


А наоборот..
При закрытии окна нужно передать данные(из textBox'a) в другую форму.

Colloseum,
классическое решение - то, что называется callback, обратный вызов, или делегат в C#.
Можно, например, создать класс



Далее, в форме, которая должна получать текст из диалога, инициализировать слушателя события callbackEvent :



А в диалоге при его закрытии создавать событие :



Таким образом, при закрытии диалога произойдёт событие, аргумент которого - текст из TextBox'a. Другая форма зарегестрировалась на прослушку этого события, поэтому вызовется обработчик getText, в параметре которого и будет долгожданый текст.

Показанная конструкция - наиболее общая : делегат и его тип находятся в отдельном классе. Конечно, всегда лучше, если они находятся в одном из использующих классов. Всё зависит от того, как ты хочешь организовать программу.

Это сообщение отредактировал(а) marcusmae - 2.9.2006, 20:36

Есть, на мой взгляд, более простое решение.
Есть две формы: MainForm - главная форма, и Form1 - форма, из которой нужно вытащить данные.
Кидаем на вторую форму текст-бокс и кнопку. Пишем своиство:

Обработчик нажатия на кнопку:

Ну и на главной форме кнопка, по нажатию на которую создается Form1:

Смотрим, что за DialogResult нам вернули, и если это ОК, то в мессаджбоксе видим то, что было введено в текстбокс в дочерней форме.

Это сообщение отредактировал(а) reloni - 2.9.2006, 22:18

Если уж на то пошло, DialogResult тут, по-моему, мало нужен. Достаточно будет создать public - поле/свойство с текстом в форме и отправлять туда текст при закрытии диалога.
Думаю, ничто не мешает вообще переопределить в наследуемом классе DialogResult, сделать его string и возвращать текст. Да вот только, всё это будет работать только когда возвращать нужно туда же, откуда диалог вызвали... 

В любом случае, речь идёт о степени корявости кода программы, которую разработчики могут увеличивать до тех пор, пока программа не начнёт казаться интеллектуальной по части разнообразия возникающих ошибок. Общепринятый подход к созданию корявости - это, всё-таки, делегаты   


Это сообщение отредактировал(а) marcusmae - 3.9.2006, 01:13

marcusmae, это если нужно выполнять какие-то действия если результ ОК, а другие, если он Cancel допустим. А про делегаты спасибо, не знал