• 15 апреля стартует «Курс «SQL-injection Master» ©» от команды The Codeby

    За 3 месяца вы пройдете путь от начальных навыков работы с SQL-запросами к базам данных до продвинутых техник. Научитесь находить уязвимости связанные с базами данных, и внедрять произвольный SQL-код в уязвимые приложения.

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

    Запись на курс до 25 апреля. Получить промодоступ ...

Цикл по однотипным компонентам формы

  • Автор темы Kassad
  • Дата начала
Статус
Закрыто для дальнейших ответов.
K

Kassad

Поискал по форуму, но ответа не нашёл. Нужно организовать цикл по однотипным компонентам формы чтобы менять/проверять их параметры. Например узнать состояние 32 радио-баттон на форме. Не могу сообразить как такое сделать в цикле.
 
L

LAW

Не знаю как реализовать конкретно, но подозреваю, что нужно создать массив-структуру, в которую поместить объекты, а потом обращиться к ним по индексу.

Народ! Кто знает? Откликнитесь! Мне тоже такая штука нужна будет скоро. :)
 
G

grigsoft

Если ты под Windows, то GetTopWindow\GetNextWindow(GW_HWNDNEXT) + GetClassName.
 
S

SNike

В Delphi это можно сделать так:

Код:
 for I:= 0 to Form1.ControlCount-1 do
ShowMessage(Form1.Controls[i].ClassName);

Думаю что в С тоже такое есть.
Просто используем свойство формы ControlCount. А контролировать тот ли это тип контрола - дело прикладное. Например, можно вот так:

Код:
 for I:= 0 to Form1.ControlCount-1 do
if Form1.Controls[i].ClassNameIs('TButton')
then ShowMessage('Нашли кнопку');

Для сравнения так же можно использовать такие методы контролов как Class, ClassType.
Просто стоит поискать их аналоги в на языке С, думаю они есть
 
L

LAW

Хм. Искать компоненты на своей же форме, а потом по Name разбираться то я нашёл или нет - это интересный способ, но я бы предпочёл способ, когда можно самому из нужных компонентов создать массив указателей на компоненты тех же радио-баттон и обращаться к ним типа:
Код:
if (myRadioButtons[1]->Checked) 
if (myRadioButtons[2]->Checked) 
if (myRadioButtons[3]->Checked)

Вот только что это за myRadioButtons и как его описать?
 
E

European

В Билдере есть функция FindComponent, которая решает похожие задачи. К сожалению Билдера рядом нет, так что подробнее не скажу
 
G

grigsoft

Если такой подход интересует, то надо тщательнее описывать. Тогда уж лучше так:
Код:
UINT anIDs[]={ID1, ID2, ID3};
...
for (int i=0; i<sizeof(anIDs)/sizeof(anIDs[0]); i++)
{
CWnd* pW = GetDlgItem(anIDs[i]);
....
}
 
Z

zubr

Поискал по форуму, но ответа не нашёл. Нужно организовать цикл по однотипным компонентам формы чтобы менять/проверять их параметры.
Плохо искал. Посмотри здесь
 
L

LAW

FindComponent решает мои проблемы, но мой вопрос (выше) по поводу массива указателей на компоненты остаётся открытым.
С ним бы было просто удобней работать. Я не знаю, может это и просто невозможно спрограммировать?
 
E

European

Так а что, нельзя получить адреса экземпляров компонент? Ну вот и положи их в массив, если очень надо
 
S

SNike

Хм. Искать компоненты на своей же форме, а потом по Name разбираться то я нашёл или нет - это интересный способ, но я бы предпочёл способ, когда можно самому из нужных компонентов создать массив указателей на компоненты тех же радио-баттон и обращаться к ним типа:
Код:
if (myRadioButtons[1]->Checked) 
if (myRadioButtons[2]->Checked) 
if (myRadioButtons[3]->Checked)

Вот только что это за myRadioButtons и как его описать?

Сравнение идет не по Name, а по ClassName, что совсем разные вещи. И это лишь вариант, а не руководство к действию. Есть другие способы. Например, сравнивать с существующим классом, использовать AS с контролем на ошибку и т.д.
А вот если использовать FindComponent - то тогда точно придется использовать Name, что нибудь типа TEdit1. И стоит сделать осмысленные названия тогда унифицированность пропадет.

По поводу myRadioButtons[1] - никто не мешает создать скажем коллекцию или какой нибудь лист чтоб в нем хранить указатели на нужные элементы.

Мое мнение - всеж сравнивать по имени класса. Или использовать коллекцию указателей где будут только нужные данные и тогда поиск отпадет.
 
Z

zubr

Компонент является объектом, а значит с ним можно связать какие нибудь данные, в частном случае номер в массиве. К примеру у всех компонентов есть пустое свойство Tag. Что мешает в данном свойстве запоминать индекс компонента в массиве? С помощью перечисления в цикле, проверяем нужного ли класса компонент, если нужного, читаем его свойство Tag, то бишь определяем индекс компонента в массиве.
 
L

LAW

Или использовать коллекцию указателей где будут только нужные данные и тогда поиск отпадет.
Именно такую коллекцию я и хочу создать.

2SNike & zubr
Спасибо. Интересные мысли. Бум пробовать :)
 
Статус
Закрыто для дальнейших ответов.
Мы в соцсетях:

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