Як організувати Ім’я Значення у CheckListBox
Добридень. Підкажіть як організувати в CheckListBox щось на зразок Ім'я = значення. А саме, наприклад, є CheckListBox1 такого плану _ _ Ім'я1 _ _ Ім'я2 _ _ Ім'я3
І якщо я ставлю галочку на будь-якому з цих імен, у мене вискакує OpenDialog і мені потрібно організувати присвоєння шляху до файлу вибраного імені. Тобто. Ім'я2 = З:\KillAll.bat
1. Завести TStringList відповідностей 2. Використовувати Objects у Items:TStrings
А можна детальніше? Я вже думав на цю тему але як саме це продати недозрозумів. плз підкажіть
ось так начебто? чи ні? bat";
1: ss:="C:\kill_ne_all.bat";
2: ss:="C:\kill.bat";
else: ss:="C:\killall.bat";
end;
OpenDialog1.FileName:=ss;
if OpenDialog1.Execute then ShowMessage(OpenDialog1.FileName);
end;
Її треба навпаки.
_
_ Скани паспорта
_
_ Скані пенсіонки
_
_ Інше
Поставили галочку наприклад на "Скани паспорта" вилітає Опендіалог і
FNAME присвоюється CheckListBox1.Items.Яке_небудь_властивість.[CheckListBox1.ItemIndex] де
Items.Objects
присвоїти можна що завгодно, не забувши виділити пам'ять у купі і звільнити потім
Еммм ну дайте шматочок коду ПЛЗ
Простіше завести масив рядків або ще один TStrings.
> Простіше завести масив рядків або ще один TStrings
не, з Items.Objects все-таки простіше
procedure TForm1.FormCreate(Sender: TObject);
begin
з CheckListBox1.Items do begin
AddObject("Ім'я1", TObject(PChar("З:rillAll.bat")));
AddObject("Ім'я2", TObject(PChar("З:\kill_ne_all.bat"))));
AddObject("Ім'я3",TObject(PChar("С: kill.bat")));
AddObject("Ім'я4", TObject(PChar("З:\kill_simple_kill.bat"))));
end;
end;
procedure TForm1.CheckListBox1ClickCheck(Sender: TObject);
begin
з TCheckListBox(Sender) do
ShowMessage(PChar(Items.Objects[ItemIndex])));
і все, а з другим TStrings ще синхронізуватися постійно
Які світові? Які константи? Це ж OpenDialog.FileName.
> Які світові? Які константи?
ті які підуть туди -> AddObject("Ім'я1", TObject(PChar("З:\rillAll.bat")));
а OpenDialog.FileName тут зовсім не до чого.
p.s. якщо проти спробуй так використовувати локальні змінні рядків, і подивися що буде.
(рядки обов'язково, тому що саме я їх пропонував для автоматизації, коли говорив, що можна уникнути виділення пам'яті/звільнення при використанні Items.Objects)
p.p.s. звідки ти OpenDialog.FileName узяв, незрозуміло, я його взагалі не згадував. ні, можна звичайно і в ньому "збережений" так рядок використовувати, але це не принципово, можна і для іншого. Тема то не про те як вона використовуватиметься, вона про те як "організувати".
З сабжа, звісно. Тому й кажу - загрожує глюками. StringList для початківців простіше та надійніше.
> StringList для початківців простіше і надійніше.
+1
Тим більше що з сабжа ніяк не випливає необхідність "синхронізації" двох списків рядків. Дивно, що Тимур відмовчується. :)
> чревато глюками.
тому і попередив про глобальність змінних, константи та зміни. якщо не розуміти, що відбувається, то легко глюків наробити, як і з усім іншим.
> Тим більше що з сабжа ніяк не випливає необхідність "синхронізації" двох списків рядків.синхронізації випливає з того простого факту, що списків буде 2 один в компоненті інший для значень, а значить і значення в них додавати/видаляти потрібно строго синхронно, щоб індекси (номер у списку) збігалися.
В даному випадку я скористався властивістю Objects Так як на мій погляд це дуже практично неодмінно мого випадку.
Код для тих, кому раптом знадобиться (Таким же нубам як і я :-) )
type
TMyObject = class (TObject)
public
s:string;
end;
procedure TForm1.c1ClickCheck(Sender: TObject);
begin
c1.Items.Objects[c1.ItemIndex]:=TMyObject.Create;
з c1.Items.Objects[c1.ItemIndex] як TMyObject do
begin
s:="lalala"+inttostr(c1.ItemIndex);
end;
end;
procedure TForm1.Button1Click(Sender: TObject); var i:integer; i] then ShowMessage(TMyObject(c1.Items.Objects[i]).s); end; відповідно очищення здійснюється c1.Items.Objects[c1.ItemIndex].Free;
На мій погляд зручно та зрозуміло.
procedure TForm1.c1ClickCheck(Sender: TObject); begin c1.Items.Objects[c1.ItemIndex]:=TMyObject.Create; з c1.Items.Objects[c1.ItemIndex] як TMyObject do begin s:="lalala"+inttostr(c1.ItemIndex); end; end; Що буде якщо на "чекбар" в c1 натиснуть 2 рази, 3, 10, і т.д. ?
Не ну ет я передбачив. якщо галку ставлять то йде CREATE якщо галку знімають то йде FREE
If (CheckListBox1.Checked[CheckListBox1.ItemIndex]=false) Then begin іf Assigned(CheckListBox1.Items.Objects[CheckListBox1.ItemIndex]) then CheckListBox1.Items.Objects[CheckListBox1.Item end;
1 Assigned працює лише якщо змінна " порожня " , тобто. за твоїм кодом 1 раз. а натискань наприклад 10. і . 2 Free, та й будь-якийінший метод викликаний у зруйнованого об'єкта призводить до AV. якщо об'єкт звільнено, але в пам'яті ще не перезаписано іншими даними. то AV може і не бути, що дасть ілюзію нормальної працездатності, але .
набагато простіше і надійніше створювати об'єкт 1 раз, попередньо перевіривши є він там чи ні. і все.
Що означає кілька разів? У моєму випадку одне виключає інше. Поставили галку створили об'єкт, прибрали галку знищили об'єкт. Іншому бути не може. Ну і як показує практика, все чудово працює
> Поставили галку, створили об'єкт, прибрали галку, знищили об'єкт. Іншому бути не може. тоді перевірка на Assigned зайва. т.к. вона по-перше тут не працює, по-друге тут від неї нічого не залежить.
> Ну і як показує практика, все чудово працює практика без теорії призводить до сумних результатів. ось як тут, наприклад. нібито правильно працює але чому не зрозумів, а варто таку ж конструкцію в іншому місці використовувати, де перевірка на Assigned буде значуща (від неї щось залежатиме), і буде нове питання на форумі типу "в одному місці працює в іншому немає хоч код однаковий. чому?
Ок. Ваш варіант. Правильний. Прошу до "Студії" Цікаво
> [21] Neket (30.06.09 9:50) > Поставили галку створили об'єкт, прибрали галку знищили об'єктЦе логічно не вірно. Тобто. з боку логіки програми - вірно, а з боку програміста - ні. Через місяць внесеш зміни в код і все. прощай логіку. ніфіка не працює, а чому? Тому що програміст писав за принципом: Працює зараз та й нехай працює, а що там не так мені покакати.
> [23] Neket (30.06.09 10:23) & gt; Ок. Ваш варіант. Правильний. Прошу в "Студію" ЦікавоНевже зсказаного вище немає міркувань на правильний код. :)
> Ок. Ваш варінт. Це не мій варіант, це твій тільки поправлений. я б у цьому випадку взагалі не робив створінь/знищень у процесі роботи програми, а створив би всі об'єкти списку при старті проги. (Не такі вже вони "напружені" щоб на них заощаджувати)
procedure TForm1.c1ClickCheck(Sender: TObject); begin з CheckListBox1 до якщо не було Assigned(Items.Objects[ItemIndex]) then begin Items.Objects[ItemIndex]:= TMyObject.Create ; з Items.Objects[ItemIndex] як TMyObject do s:="lalala"+inttostr(c1.ItemIndex); end; end;
причому помилка буде рідкісною, важко вловимою, незрозуміло від яких дій (жоден користувач тобі послідовність не запам'ятає), і виникне тільки тоді, коли програма "розростеться" там з'являться додаткові пункти (типу "відзначити все"), буде використовуватися багато пам'яті, і стане важкою у налагодженні, т.к. у налагодженні ті ж дії повторені відразу (об'єкт може ще не зруйнується) AV не дадуть.
> CheckListBox1.Items.Objects[0]:= TObject(PChar("doError")); ось це краще замінити на це - PInteger(CheckListBox1.Items.Objects[0])^:= 1234;
sniknikУ твоєму прикладі дія s:="lalala"+inttostr(c1.ItemIndex); виконується лише один раз. А судячи з умов завдання воно має змінюватися при кожному "чеку", коли вибирається ім'я файла. Але в цьому випадку потрібно ще бути впевненим, що Objects [N] є об'єктом типу TMyObject.
> А судячи з умов завдання воно має змінюватися при кожному "чеку" і в чому проблема? у тому, що аналізований приклад не є готовим для копі пасті рішенням? так це саме те для розуміння.
> Але в цьому випадку ще потрібно бути впевненим, що Objects[N] є об'єктом типуTMyObject. з проектом працює кілька людей, і один не знає що туди вносить інший? яка ще потрібна впевненість?
Хмм. Цікаво. Дякую. ввібрав. Бум виправлятиметься. Хоча в моєму випадку можна було б і зупинитися на тому, що є так глибоко я лізти не буду, але я в принципі є прихильником універсальності і коректності. Тому із принципу внесу зміни. Ще раз дякую.
> але я в принципі є прихильником універсальності та коректності. > Тому з принципу внесу зміни.не з принципу, а так правильно
> так це саме те для розуміння. А якщо людина не поділяє створення об'єкта зі зміною його властивостей, і не може самостійно винести зміну з умови створення. Ну скажіть про це відразу. і не варто мені тоді більше з цією людиною розмовляти, навіть у початківців. треба робити розділ "ясла" на форумі та посилати таких туди.
як завжди кінцівка тішить. "ВСЕ В САД" )))) Все одно дякую
> як завжди кінцівка тішить. "ВСЕ В САД" )))) Все одно спасибі ну, це взагалі то не тобі, це продовження відповіді для Jungle.
тебе я спочатку не вважав нездатним розібратися, хоча мене й остерігали, що треба писати як для початківців. подібне [31] було б особисто для тебе, а так ні)
> тебе я спочатку не вважав я взагалі спочатку нікого не вважаю. хіба що якщо з першого посту починають нести "неадекват".
Дякую. Може просто невмію відразу коректно пояснити проблему)))