View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001939 | SAS.Планета | Рефакторинг / Refactoring | public | 29-05-2013 14:58 | 02-07-2013 06:46 |
| Reporter | vdemidov | Assigned To | Garl | ||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | resolved | Resolution | fixed | ||
| Product Version | 121010 | ||||
| Target Version | 131111 | Fixed in Version | 131111 | ||
| Summary | 0001939: Сделать универсальный фрейм выбора карты | ||||
| Description | Хорошо бы сделать универсальный механизм выбора карты для всех операций с выделенной областью. Таких мест где требуется выбор карты сейчас достаточно много и код заполнения комбобоксов списком карт дублируется. ИМХО фрейм в конструкторе должен получать: 1. Признак возможности выбора "Нет" (То есть, нужно ли добавлять такой пункт в списке карт) 2. Тип выбираемых карт (Только карты, только слои, все подряд) 3. функцию проверки нужна ли в списке конкретная карта (function(AMapType: TMapType): boolean of object;) + еще объекты которые ему для работы понадобятся. Необходимо сделать метод GetSelectedMap Плюс, возможно метод Init | ||||
| Tags | No tags attached. | ||||
|
|
я бы ещё добавил отбор по типу кэша и по проекции карты |
|
|
Ну, коль: >Ответственный Garl так тебе и карты в руки :) |
|
|
>я бы ещё добавил отбор по типу кэша и по проекции карты Ну я бы для начала перенес существенный функционал в фрейм, а уже потом можно допиливать новые фильтрации и тд. |
|
|
функция будет выдавать необходимость карты в списке в зависимости от установленного в init() фильтра (по всяким параметрам) или я не улавливаю логики... |
|
|
В ините никаких параметров быть не должно быть. Все что касается отбора пусть в конструкторе фрейма передается. |
|
|
Ааа. Понял. Ты про функцию которую передавать в конструктор? Так в ней каждый потребитель напишет проверки, которые ему нужны. Например: function TfrTilesDelete.CheckIsDeleteable(AMapType: TMapType): boolean; begin result := AMapType.StorageConfig.AllowDelete; end; |
|
|
такс, с TfrTilesDelete может пока не заморачиваемся? сделаем готовый и рабочий вариант для одного фрейма, а затем потихоньку будем пилить для остальных. { TfrMapSelect } constructor TfrMapSelect.Create( const ALanguageManager: ILanguageManager; const AMainMapsConfig: IMainMapsConfig; const AGUIConfigList: IMapTypeGUIConfigList; const AFullMapsSet: IMapTypeSet; const AActiveMapGUID: TGUID; const AMenuFiter : TMapSelectMenuFilter ); в init() нет параметров, зачем он вообще тогда нужен, если можно видимость пунктов контекстного меню и в create() запилить с функцией в конструкторе есть у нас где-нибудь рабочий пример, чтото не въезжаю в логику, надо посмортреть на рабочий вариант... |
|
|
TMapSelectMenuFilter должно быть простым перечислением на три значения (Только карты, только слои, все подряд) >в init() нет параметров, зачем он вообще тогда нужен, если можно видимость пунктов контекстного меню и в create() запилить Нельзя в конструкторе. Заполнение списка карт должно быть именно в init, а вызываться он должен в init фрейма владельца. И обновляться список карт должен при каждом вызове Init - вдруг какую-то карту отключили и включили. >с функцией в конструкторе есть у нас где-нибудь рабочий пример, чтото не въезжаю в логику, надо посмортреть на рабочий вариант... Ну например любой листенер получает процедуру объекта при создании. Только тебе нужна не процедура, а функция. |
|
|
во, теперь мозаика складывается. >(Только карты, только слои, все подряд) активные и фильтр выкидываем? |
|
|
>активные и фильтр выкидываем? А смысл их снаружи? Это все внутри нового фрейма спрячется. Будет настраиваться через поп-ап менюшку внутри фрейма и совсем не будет волновать фрейма-владельца. |
|
|
тоесть Активные и Фильтр по названию - будут присутствовать всегда? остальное по перечислению. |
|
|
>тоесть Активные и Фильтр по названию - будут присутствовать всегда А зачем их отключать? Разве что активные можно отключать, если выбраны только карты без слоев. |
|
|
ага пункт активные при режиме mm_maps будет скрываться. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 29-05-2013 14:58 | vdemidov | New Issue | |
| 29-05-2013 14:58 | vdemidov | Status | new => assigned |
| 29-05-2013 14:58 | vdemidov | Assigned To | => Garl |
| 29-05-2013 17:45 | Garl | Note Added: 0011457 | |
| 29-05-2013 18:07 | zed | Note Added: 0011458 | |
| 30-05-2013 10:44 | vdemidov | Note Added: 0011463 | |
| 03-06-2013 19:28 | Garl | Note Added: 0011496 | |
| 03-06-2013 19:32 | vdemidov | Note Added: 0011497 | |
| 03-06-2013 19:40 | vdemidov | Note Added: 0011498 | |
| 04-06-2013 09:52 | Garl | Note Added: 0011499 | |
| 04-06-2013 10:15 | vdemidov | Note Added: 0011500 | |
| 04-06-2013 10:21 | Garl | Note Added: 0011501 | |
| 04-06-2013 10:27 | vdemidov | Note Added: 0011502 | |
| 04-06-2013 10:47 | Garl | Note Added: 0011503 | |
| 04-06-2013 11:28 | vdemidov | Note Added: 0011504 | |
| 04-06-2013 11:30 | Garl | Note Added: 0011505 | |
| 25-06-2013 10:16 | Garl | Status | assigned => resolved |
| 25-06-2013 10:16 | Garl | Fixed in Version | => 131111 |
| 25-06-2013 10:16 | Garl | Target Version | 41xxxx => 131111 |
| 02-07-2013 06:46 | vdemidov | Resolution | open => fixed |
| 11-07-2013 15:15 | zed | Relationship added | related to 0002015 |
| 08-08-2025 13:25 | zed | Category | Рефакторинг => Рефакторинг / Refactoring |