for flooders
:: Главная :: Решения :: Статьи :: Сайт М. Дроздова :: Файловый архив :: Книга по VFP 9 :: Русский Help Online :: OFF-LINE Форум
   Лисоводы   всех   стран,  объединяйтесь !!!  

Список Форумов  :: Visual Foxpro, Foxpro for DOS
  

Select SQL - to Aleksey Tsingauz [MSFT]...
piva
Автор

Сообщений: 18600
Откуда: Курган
Дата: 12.07.04 10:23:20
Если в vfp9 сделали коллекции доступными для ListBoх - вдруг в релизе прикрутят к grid - по почему- бы не сделать выборку в коллекцию ?
А что - классно было бы

Select ... into collection oMyCollection
Ratings: 0 negative/0 positive

Re: Select SQL - to Aleksey Tsingauz [MSFT]...
Syberex

Сообщений: 1432
Откуда: Кострома
Дата: 12.07.04 16:25:43
А какая, в данном случае, будет разница между массивом и коллекцией?




------------------
Ratings: 0 negative/0 positive

Re: Select SQL - to Aleksey Tsingauz [MSFT]...
Igor Korolyov

Сообщений: 34119
Дата: 13.07.04 03:57:29
В массиве доступ только по индексу, а в коллекции - по индексу или
ключу
. Правда не совсем ясно что же будут представлять собой элементы
колекции - то-ли коллекции полей (индекс - имя поля), то-ли такой-же
Empty-объект что и по SCATTER NAME получается...
Однако IMHO это не самое крутое - самое крутое было-бы реализовать Grid
вообще без привязки к источнику данных - чтоб он запрашивал данные через
какой-то свой Event типа GetCell, или GetRow... Ну ессно "предполагаемое
число строк" надо задавать явно - зато потом рули себе динамически загрузкой
данных - ну т.е. примерно как делает сам Grid объект, или банальнейший
BROWSE (он же качает только те записи что надо для "заполнения видимой
области")... Да, мечты, мечты... Ведь даже Объектного меню не сделали, хотя
AFAIK в Top 10 вишей оно было наряду с ОО-репортером...

P.S. За прошлую неделю в FIDO7.RU.VISUAL.FOXPRO описали 2 явных бага (индекс
UPPER(символьное_русское_поле) по таблице в 866-й CP и несохранение
пользовательских свойств для субклассированных колонок в гриде) которые
присуствуют в VFP9 Public Beta по наследству от VFP8 и более ранних. И 1
неплохой виш (про позицию курсора в текстбоксе лимитированном маской или
MaxLength - не перед последним введённым символом, а после
него). Правда я не уверен что эти уважаемые (и очевидно очень занятые)
господа найдут время оформить багрепорт
Aleksey, вы видели эти сообщения? Если нет, то вот их MSGID - по ним их
просто найти...
Message-ID: <ccg3u1$23nr$1@ddt.demos.su>
Message-ID: <ccimk9$1mo$1@host.talk.ru>
Message-ID: <1565867865.20040707093122@tsrv.ru>




------------------
WBR, Igor
Ratings: 0 negative/0 positive

Re: Select SQL - to Aleksey Tsingauz [MSFT]...
Aleksey Tsingauz [MSFT]
Дата: 14.07.04 05:57:53
Цитата:
Если в vfp9 сделали коллекции доступными для ListBoх - вдруг в релизе прикрутят к grid - по почему- бы не сделать выборку в коллекцию ?

Здравствуйте, Вадим!

В настоящее время, мы не планируем добавит поддержку Collection в Grid.

Aleksey Tsingauz
Visual FoxPro Dev Team
Ratings: 0 negative/0 positive

Re: Select SQL - to Aleksey Tsingauz [MSFT]...
Aleksey Tsingauz [MSFT]
Дата: 14.07.04 06:18:27
Цитата:
P.S. За прошлую неделю в FIDO7.RU.VISUAL.FOXPRO описали 2 явных бага (индекс
UPPER(символьное_русское_поле) по таблице в 866-й CP и несохранение
пользовательских свойств для субклассированных колонок в гриде) которые
присуствуют в VFP9 Public Beta по наследству от VFP8 и более ранних. И 1
неплохой виш (про позицию курсора в текстбоксе лимитированном маской или
MaxLength - не перед последним введённым символом, а после
него). Правда я не уверен что эти уважаемые (и очевидно очень занятые)
господа найдут время оформить багрепорт
Aleksey, вы видели эти сообщения? Если нет, то вот их MSGID - по ним их
просто найти...
 Message-ID: <ccg3u1$23nr$1@ddt.demos.su>
 Message-ID: <ccimk9$1mo$1@host.talk.ru>
 Message-ID: <1565867865.20040707093122@tsrv.ru>


Здравствуйте, Игорь!

Понятия не имею как использовать эти MSGID для поиска сообщений. Просветите, пожалуйста. Я предпочитаю читать FIDO7.RU.VISUAL.FOXPRO через Outlook Express, так что если бы вы включили Subject и дату, то было бы хорошо.

Пока что из этих трех я видел только одно - про UPPER. К сожалению, сообщение не содержит ни репро кода, ни описания как выглядит "белиберда" и "полная ерунда", ни описание ожидаемого результата. Я так понимаю, что вы знаете о чем идет речь. Пожалуйста, поделитесь.

Aleksey Tsingauz
Visual FoxPro Dev Team

Ratings: 0 negative/0 positive

Re: Select SQL - to Aleksey Tsingauz [MSFT]...
piva
Автор

Сообщений: 18600
Откуда: Курган
Дата: 14.07.04 06:36:06
Здравствуйте Алексей

Про Collection для Grid, понятно, а Collection для Select SQL, видимо тоже не будет ?
Ratings: 0 negative/0 positive

Re: Select SQL - to Aleksey Tsingauz [MSFT]...
Aleksey Tsingauz [MSFT]
Дата: 14.07.04 10:28:10
Цитата:
Про Collection для Grid, понятно, а Collection для Select SQL, видимо тоже не будет ?

Вадим, намёк вы поняли правильно. Изменения такого рода имеет низкий приоритет потому что всегда можно написать SCAN цикл и заполнить Collection именно так как вы хотите. Ведь представление результата в виде Collection не совсем однозначно:

Создавать Collection с ключем или без?
Если с ключем, то что выступает в роли ключа? Текстовое представление номера записи или что-то еще?
Что выступает в роли элемента Collection? Другая Collection, массив, SCATTER объект?

Делать что-то одно, многие остануться недовольны - не сделали так как им надо. Делать все - надо много времени на разработку и еще больше на тестирование.

Aleksey Tsingauz
Visual FoxPro Dev Team

Ratings: 0 negative/0 positive

Re: Select SQL - to Aleksey Tsingauz [MSFT]...
piva
Автор

Сообщений: 18600
Откуда: Курган
Дата: 14.07.04 10:31:33
Ну не будет - так не будет. Чего-нибудь сами придумаем.

Спасибо
Ratings: 0 negative/0 positive

Re: Select SQL - to Aleksey Tsingauz [MSFT]...
Igor Korolyov

Сообщений: 34119
Дата: 14.07.04 14:57:21
Набрать в любом понимающем URL-ы окне (IE, Explorer, да хоть и Run адрес
следующего вида:
news://ddt.demos.su/ccg3u1$23nr$1@ddt.demos.su
Где вместо доменного адреса (не тот что часть MSGID!) ddt.demos.su можно
указать свой гейт (только чтоб он не требовал авторизацию).
Или пойти на Google и там в расширенном групповом поиске искать по
идентификатору - получится URL вида:
[url]http://www.google.com/groups?ie=UTF-8&as_umsgid=ccg3u1%2423nr%241@ddt.demos.su[/url]

Замечу только что "нехорошие символы" в MSGID будут перекодированы в
соответствии со схемой URLEncode (% + hex код символа).
Цитата:
Я предпочитаю читать FIDO7.RU.VISUAL.FOXPRO через Outlook Express,
так что если бы вы включили Subject и дату, то было бы хорошо.
Я
тоже, (надстройкой к OE стоит Fidolook) но к сожалению там нету поиска по
MSGID, надеюсь что только пока
Цитата:
Пока что из этих трех я видел только одно - про UPPER.
Уточняю:
  
  CREATE TABLE bad866 FREE CODEPAGE=866 (nID I, cName C(1))  
    
  FOR ln1 = 32 TO 255  
   INSERT INTO bad866 (nID, cName) VALUES(ln1, CHR(m.ln1))  
  ENDFOR  
  INDEX ON UPPER(cName) TAG cName COLLATE 'MACHINE'  
  BROWSE

Кстати там и к "без UPPER" есть свои вопросы. В смысле MACHINE как-то не
"машинит"... Т.е. пытается не по ASCII кодам сортировать, а по каким-то
перекодированным кодам.




------------------
WBR, Igor
Ratings: 0 negative/0 positive

Re: Select SQL - to Aleksey Tsingauz [MSFT]...
Aleksey Tsingauz [MSFT]
Дата: 16.07.04 12:55:37
Цитата:
Уточняю:
  
   CREATE TABLE bad866 FREE CODEPAGE=866 (nID I, cName C(1))  
     
   FOR ln1 = 32 TO 255  
    INSERT INTO bad866 (nID, cName) VALUES(ln1, CHR(m.ln1))  
   ENDFOR  
   INDEX ON UPPER(cName) TAG cName COLLATE 'MACHINE'  
   BROWSE

Кстати там и к "без UPPER" есть свои вопросы. В смысле MACHINE как-то не
"машинит"... Т.е. пытается не по ASCII кодам сортировать, а по каким-то
перекодированным кодам.

Здравствуйте, Игорь!

Да вроде все тут "машинит" и результат вполне объясним. При построении идекса нужно учитывать следующую деталь. Когда индексное выражение вычисляется, значения полей читаются с диска как есть, без трансляции в текущую кодовою страницу. А вот многие функции оперируют по разному, в зависимости от текущей кодовой страницы. UPPER один из примеров такой функции. Если текущая кодовая страница 1251 а кодовая страница таблицы 866, то к букве "а" в кодировке 866 UPPER применит кодовую страницу 1251. Естественно, буквы "А" в кодировке 866 не получится. Если планируется строить индексы или модифицировать данные под разными текущими кодовыми страницами, то индексное выражение должно быть инвариантно отностельно текущей кодовой страницы. Например, в данном случае можно использовать:
INDEX ON CPCONVERT(1251,866,STRCONV(CPCONVERT(866,1251,cName),8,1049)) TAG cName COLLATE 'MACHINE'
А можно просто положиться на COLLATE 'RUSSIAN' и вообще не связываться с преобразованием регистра букв.

Aleksey Tsingauz
Visual FoxPro Dev Team

Ratings: 0 negative/0 positive

Re: Select SQL - to Aleksey Tsingauz [MSFT]...
Igor Korolyov

Сообщений: 34119
Дата: 16.07.04 18:21:51
1) Полагаться на RUSSIAN я бы не стал по простой причине:

SET COLLATE TO "RUSSIAN"
? CHR(1) = CHR(2)
? BINTOC(1) = BINTOC(2)

Соответственно и для таблиц с составными индексными ключами (например
"агрегатов" реализующих связи много-ко-многим). Результат JOIN скажем будет
неверный (а "сцеплять" иначе 2 INTEGER-поля IMHO неразумно). Постоянно
дёргать же COLLATE тоже не есть хорошо, да и Rushmore не поймёт меня...

2) По поводу "не машинит": Убираем из примера UPPER (делаем тривиальный
индекс по полю) и наблюдаем что например в самом начале идёт так (по кодам
символов):
187
171
182
167
32
33
Что никак не соответствует моему пониманию MACHINE. Меняем в примере
CODEPAGE=1251 и наблюдаем ожидаемое поведение - упорядочено именно по кодам.
Я уж не знаю на каком этапе создания индекса происходит конвертация, но она
явно происходит (причём даже без всяких UPPER).
Причём баг явно обнаруживается и в VFP8SP1 (возможно и в более старых).

3) Снова вернёмся к COLLATE "RUSSIAN" - в вышеуказанном примере делаем
индекс
INDEX ON UPPER(cName) TAG cName COLLATE 'RUSSIAN'
И наблюдаем... Да, опять полная неразбериха. Где буковка я, и где ш



[i][small][color=Gray]Отредактировано (17.07.04 03:52)


------------------
WBR, Igor
Ratings: 0 negative/0 positive

Re: Select SQL - to Aleksey Tsingauz [MSFT]...
Aleksey Tsingauz [MSFT]
Дата: 17.07.04 07:55:35
Здравствуйте, Игорь!

Цитата:
1) Полагаться на RUSSIAN я бы не стал по простой причине:
SET COLLATE TO "RUSSIAN"
? CHR(1) = CHR(2)
? BINTOC(1) = BINTOC(2)

Не подходит, так не подходит, вам виднее для чего вы строите индекс. Я посчитал, что цель использования UPPER - добится сортировки нечувствительной к регистру букв. В этом случае, использование "Russian" collate может быть приемлемо.

Цитата:
2) По поводу "не машинит": Убираем из примера UPPER (делаем тривиальный
индекс по полю) и наблюдаем что например в самом начале идёт так (по кодам
символов):
 187
 171
 182
 167
 32
 33
Что никак не соответствует моему пониманию MACHINE. Меняем в примере
CODEPAGE=1251 и наблюдаем ожидаемое поведение - упорядочено именно по кодам.
Я уж не знаю на каком этапе создания индекса происходит конвертация, но она
явно происходит (причём даже без всяких UPPER).
Причём баг явно обнаруживается и в VFP8SP1 (возможно и в более старых).

Да никакой это не баг, а ожидаемый результат. Давайте пойдем по шагам.
1) В VFP с CPCURRENT()==1251 запускаем следующий код:
  
  CREATE TABLE test866 FREE CODEPAGE=866 (nID I, cName C(1), cBin Q(1) )    
        
  FOR ln1 = 32 TO 255    
     INSERT INTO test866 (nID, cName, cBin ) VALUES(ln1, CHR(m.ln1), CPCONVERT(1251,866,CHR(m.ln1)))    
  ENDFOR
Что же при этом происходит? А происходит то, что значения записываемые в cName будут предварительно переведены из кодовой страницы 1251 в кодовую страницу 866. В таблицу физически будет записано CPCONVERT(1251,866,CHR(m.ln1)), а не CHR(m.ln1). Это совершенно разные значения.

2) Чтобы в этом убедится, запускаем вот такой SELECT:
  
  SELECT nID, cName, ASC(cName) ASC_cName, ASC(cBin) ASC_cBin from test866 WHERE ASC(cName)!=ASC(cBin)
Результат - 116 записей. Чтобы убедится, что cBin - это именно то, что на диске в поле сName можно запустит этот же SELECT в VFP с CPCURRENT()==866. Трансляция Char полей производится не будет и SELECT ничего не вернет.

3) Строим индекс:
  
  INDEX ON cName TAG cName COLLATE "MACHINE"
Как я уже говорил, индекс строится по данным непосредственно с диска и трансляция Char полей не производится. А значения на диске в поле cName совпадают со значениями в поле cBin.

4) Проверяем сортированную последовательность:
  
  SELECT test866  
  SET ORDER TO CNAME   && CNAME  
  BROWSE
Что мы видим? А видим мы то, что поле cBin отсортировано по возрастанию кодов, а это является идикатором того, что и поле cName отсортировано по возрастанию кодов в кодовой таблице 866.

5) Заключительная проверка. Загружаем VFP c CPCURRENT()==866 и убеждаемся, что индекс действительно отсортировал cName по возрастанию кодов (COLLATE "MACHINE"). Удаляем индекс и строим заново. Результат - получаем ту же самую последовательность.


Цитата:
3) Снова вернёмся к COLLATE "RUSSIAN" - в вышеуказанном примере делаем
индекс
INDEX ON UPPER(cName) TAG cName COLLATE 'RUSSIAN'
И наблюдаем... Да, опять полная неразбериха. Где буковка я, и где ш
Я уже объяснял в чем специфика использования функции UPPER. Oна всегда считает, что входные данные закодированы с помощью CPCURRENT(). Вы получаете то, что должны получить. Это все равно, что умножать 2*2 и ожидать 5.

Aleksey Tsingauz
Visual FoxPro Dev Team

Ratings: 0 negative/0 positive

Re: Select SQL - to Aleksey Tsingauz [MSFT]...
Igor Korolyov

Сообщений: 34119
Дата: 18.07.04 03:33:14
Ну я примерно про то и говорил - данные "отображаемые" несоответствуют
данным "хранящимся". То что это происходит не в цепи таблица-индекс а в цепи
таблица-отображение, сути не меняет (для меня). Хотя как-то отразить эту
особенность (про работу с таблицами в "неродных" кодировках) в хелпе или
какой статье KB наверное стоит, ну чтоб по крайней мере потом не было
вопросов/претензий что "не предупредили"...




------------------
WBR, Igor
Ratings: 0 negative/0 positive

Re: Select SQL - to Aleksey Tsingauz [MSFT]...
Aleksey Tsingauz [MSFT]
Дата: 18.07.04 09:52:12
Здравствуйте, Игорь!

Цитата:
Ну я примерно про то и говорил - данные "отображаемые" несоответствуют
данным "хранящимся". То что это происходит не в цепи таблица-индекс а в цепи
таблица-отображение, сути не меняет (для меня).

А для нас это многое меняет. В принципе, в этом то и весь смысл назначения определенной кодовой страницы для таблиц. С какой целью вы создавали таблицу в кодировке 866 и не указали NOCPTRANS флаг для поля?

Цитата:
Хотя как-то отразить эту особенность (про работу с таблицами в "неродных" кодировках) в хелпе или
какой статье KB наверное стоит, ну чтоб по крайней мере потом не было
вопросов/претензий что "не предупредили"...
Вопросы - пожалуйста. А вот претензий по поводу "не предупредили" быть не должно. В документации достаточно много информации по кодовым страницам. Вот одна цитата:
*-------
Understanding Code Pages in Visual FoxPro
Visual FoxPro displays data using one code page. By default, this is the current code page used by Windows. However, you can override the Windows code page by specifying an alternative code page in your configuration file (you must specify a valid code page).

Tables in Visual FoxPro are tagged with the code page that was in use when the table was created. When you use the table, Visual FoxPro checks the code page for the table against the current code page. If they match, Visual FoxPro displays the data as is. If there is no code page for the table (for example, the table was created in an earlier version of FoxPro), Visual FoxPro prompts you for a code page and then marks the file with it.

If the table code page does not match the system code page, Visual FoxPro attempts to translate characters from the table code page into the current one. For example, if you're using Visual FoxPro and the current system code page is the English code page, the character &#252; is represented by ANSI value 252. If the code page for the table represents the &#252; character as ANSI value 219, Visual FoxPro translates all instances of ANSI value 219 into ANSI 252 so that they display properly.
*-------

Aleksey Tsingauz
Visual FoxPro Dev Team

Ratings: 0 negative/0 positive

Re: Select SQL - to Aleksey Tsingauz [MSFT]...
Igor Korolyov

Сообщений: 34119
Дата: 19.07.04 01:28:57
1) Я ничего не создавал. Это вообще не моя проблема была (хотя я и пользуюсь
таблицами созданными в FPD/Clipper т.е. 866 CP, но у них нету индексных
тегов, да и пользуюсь я ими лишь для "загрузки" в "правильные" таблицы -
т.е. CP 1251)
2) Мало, мало того что сказано в процитированном. Надо и про возможные
"проблемы" с индексами написать, и вообще про работу с таблицами в разных CP
в пределах одной сессии... Не обязательно в документации, возможно стоит в
KB статью написать - для тех кому это реально надо (в Штатах ясное дело
никому до того дела нету).
3) Ну и вообще я давно уже говорил что полного порядка до перевода фокса на
Unicode нет и быть не может Пока фокс работает в одной кодовой
странице единовременно (и для её смены нужно вообще полностью перегружать
среду!), никакой реальной многоязыковости добиться нельзя.

P.S. Я прекрасно понимаю все сложности связанные с переводом фокса на
Unicode, и понимаю весьма узкий рынок где это реально надо. Потому и не
говорю что это "первоочередное"... Но в перспективе, наверное стоит подумать
и про такое решение...




------------------
WBR, Igor
Ratings: 0 negative/0 positive

Re: Select SQL - to Aleksey Tsingauz [MSFT]...
Aleksey Tsingauz [MSFT]
Дата: 19.07.04 13:02:47
Здравствуйте, Игорь!

Цитата:
1) Я ничего не создавал. Это вообще не моя проблема была (хотя я и пользуюсь
таблицами созданными в FPD/Clipper т.е. 866 CP, но у них нету индексных
тегов, да и пользуюсь я ими лишь для "загрузки" в "правильные" таблицы -
т.е. CP 1251)
Мой вопрос не подразумевал под собой того, что сам факт создания такой таблицы - ошибка или плохой выбор. Скорее, он должен был подчеркнуть, что есть в этом что-то особенное. Что-то, что нельзя получить создав таблицу с кодовой страницей 1251 - хранение текста в кодовой странице 866. Соответственно, это интуитивно понятно, что данные будут транслированы, чудес то ведь не бывает.

Цитата:
2) Мало, мало того что сказано в процитированном. Надо и про возможные
"проблемы" с индексами написать, и вообще про работу с таблицами в разных CP
в пределах одной сессии... Не обязательно в документации, возможно стоит в
KB статью написать - для тех кому это реально надо (в Штатах ясное дело
никому до того дела нету).
Я не буду спорить о том нужна или нет КВ статья на эту тему. Я просто еще раз подчеркну, что в документации есть целый раздел посвященный подобного рода проблемам "Creating International Applications", приведенная цитата - это всего лишь несколько абзацев из него. У меня ушло всего две минуты на то, чтобы ее найти. Вы заметили, что цитата как раз объясняет разницу между тем, что вы "видите" и тем, что реально хранится в таблице? Мало того, что вы не потрудились сделать это сами, прежде чем списывать все на отсутствие документации, дак вы еще продолжаете судить о документации по одной этой цитате. Как-то быстро вы делаете свои заключения, вам не кажется? Признаюсь, я весь тот раздел не читал, очень вероятно, что какие-то детали там не отражены или отражены не так, как хотелось бы. Я так же не проверял есть ли существующая КВ статься на эту тему и совсем не удивлюсь если есть. Короче, при таком вашем подходе, каковы шансы, что новая КВ статья что-то изменит?

Aleksey Tsingauz
Visual FoxPro Dev Team

Ratings: 0 negative/0 positive

Re: Select SQL - to Aleksey Tsingauz [MSFT]...
Igor Korolyov

Сообщений: 34119
Дата: 19.07.04 15:47:34
Ну зачем же так плохо думать Я прочитал внимательно весь раздел, но вот
из него как раз и не вытекает описанное поведение. А по косвенным намёкам
оттуда понять что происходит очень сложно.
Уже одно то что одновременно два разных человека спрашивают в разных местах
про "это" говорит в пользу моего мнения о неясности изложения вопроса. То
что индекс строится по неперекодированным, а показ идёт в
перекодированном... Я бы без вашего описания вряд-ли догадался в чём тут
дело...




------------------
WBR, Igor
Ratings: 0 negative/0 positive

Re: Select SQL - to Aleksey Tsingauz [MSFT]...
Aleksey Tsingauz [MSFT]
Дата: 19.07.04 22:56:42
Здравствуйте, Игорь!
Цитата:
Я прочитал внимательно весь раздел
Примите мои извинения если я неправильно интерпретировал ваше сообщение.

Цитата:
То что индекс строится по неперекодированным, а показ идёт в
перекодированном... Я бы без вашего описания вряд-ли догадался в чём тут
дело...
Мы постараемся ликвидировать этот пробел в документации по VFP9.

Aleksey Tsingauz
Visual FoxPro Dev Team
Ratings: 0 negative/0 positive

Re: Select SQL - to Aleksey Tsingauz [MSFT]...
Igor Korolyov

Сообщений: 34119
Дата: 21.07.04 03:10:58
ОК

Тогда с вашего позволения ещё одно тонкое место в документации -
использование CursorAdapter с XML источниками данных - процедура генерации
XMLUpdategram-мы средствами самого CA (т.е. через CA.UpdateGram) - то что
надо в InsertCmd (ну и.т.д) прописать вызов фоксовой функции (лучше метода,
ещё лучше метода данного объекта CA) и тогда изнутри этого метода
CA.UpdateGram вернёт то что надо... В общем пока я в инете не нашёл статью с
примером (к большому сожалению он сейчас где-то затерялся и автора я
назвать затрудняюсь... Но там по всем видам источников данных вроде как
примеры и неплохие разъяснения были - да источник англоязычный) - то
приручить это свойство я никак не мог Возможно стоит договорится с
авторами и включить эту статью в документацию? Ибо по CA Walkthrough
довольно таки схематичный (и с ADO источниками для СА - я пока сам не
работал, но по "просто прочтению" не совсем всё понятно и прозрачно)
Как только найду линк, обязательно сообщу...




------------------
WBR, Igor
Ratings: 0 negative/0 positive



Извините, только зарегистрированные пользователи могут оставлять сообщения в этом форуме.

On-line: 16 (Гостей: 16)

© 2000-2021 Fox Club 
Яндекс.Метрика