:: Visual Foxpro, Foxpro for DOS
Re: Проблема с открытием таблиц в DE по заданному пути
ABB

Сообщений: 149
Откуда: Санкт-Петербург
Дата регистрации: 21.10.2006
А вот заключение ChatGPT:
Да, в данном коде есть ошибки.

Во-первых, строка `LOCAL lcPathFile as Character` должна быть помещена перед циклом `FOR EACH`, так как в цикле мы назначаем значение этой переменной. То есть, код должен выглядеть так:

*FoxPro
LOCAL lo_Object, lcPathFile, lc_Table, lc_Cursor
* Объявим переменную для назначения пути к БД
LOCAL lcPathFile as Character
FOR EACH lo_Object In Thisform.DataEnvironment.objects
* Переназначим пути к БД в ДЕ
WITH lo_Object
IF .BaseClass == 'Cursor'
* Выберем путь к БД по условию
lcPathFile = Alltrim(Iif(Upper(Alltrim(.Alias))=="PERSON", goApp.PathBdPerson, goApp.PathFile))
IF Not '\' $ .CursorSource
lc_Table = JUSTFNAME(.Database)
lc_Cursor = UPPER(.name)
.Database = lcPathFile+lc_Table
ELSE
lc_Table = JUSTFNAME(.CursorSource)
.CursorSource = lcPathFile+lc_Table
ENDIF
ENDIF
ENDWITH
ENDFOR
```
Во-вторых, внутри условия `IF Not '\' $ .CursorSource` неправильно выбран символ для проверки наличия символа "\" в строке. Вместо этого необходимо использовать функцию `INSTR`, которая проверяет нахождение подстроки в строке. То есть, строка должна быть изменена на:

```FoxPro
IF INSTR(1, .CursorSource, '\') = 0
```

Также в данном коде используются переменные `goApp.PathBdPerson` и `goApp.PathFile`, которые не объявлены в представленном коде. Однако, в зависимости от контекста программы, вероятно, они понятны и объявлены в других частях приложения.
Ratings: 0 negative/0 positive
Re: Проблема с открытием таблиц в DE по заданному пути
akvvohinc

Сообщений: 4224
Откуда: Москва
Дата регистрации: 11.11.2008
Каратаев
Вопрос чисто риторический? Ведь понятно-же, что ничего ровным счётом.
Совсем не риторический - ведь ваш ответ на предложение Сергея был другим:
Цитата:
Для порядку учёл Спасибо...
Раз учли, то, видимо, хоть какую-то разницу в этих вариантах для себя увидели.

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

Но "вылезут ли за рамки" эти переменные - не особенно страшно.
А вот то, что любая из них без описания может испортить значение PUBLIC или PRIVATE переменной, использующейся где-то выше в стеке вызовов - гораздо хуже.
Причем, даже если такого не происходит сейчас, не гарантирует, что вы не добавите одноименную переменную в будущем - никто не может помнить имена всех своих используемых в проекте переменных:
var = 1
? var && 1
DO func1
? var && 2
FUNCTION func1
var = 2 && неописанная переменная
Ratings: 0 negative/0 positive
Re: Проблема с открытием таблиц в DE по заданному пути
Каратаев

Сообщений: 3977
Откуда: Алматы
Дата регистрации: 04.12.2001
ABB
Во-вторых, внутри условия `IF Not '\' $ .CursorSource` неправильно выбран символ для проверки наличия символа "\" в строке. Вместо этого необходимо использовать функцию `INSTR`, которая проверяет нахождение подстроки в строке.
Разве? INSTR я не знаю и в Хелпе не нашёл...
Оператор $ возвращает значение "истина" (.T.), если данное символьное выражение содержится в другом символьном выражении, в противном случае возвращает "ложь" (.F.).
И в чём его неправильность?
akvvohinc
А вот то, что любая из них без описания может испортить значение PUBLIC или PRIVATE переменной, использующейся где-то...
Блин, да не спорю я! Написал же, что это только идея! Реально в программе код выглядит так:
* объявим переменные для назначения пути к БД
LOCAL lcPathFile as String, lo_Object as Object, lc_Table as String, lc_Cursor as String
FOR EACH lo_Object In Thisform.DataEnvironment.objects
* Переназначим пути к БД в ДЕ
WITH lo_Object
IF .BaseClass == 'Cursor'
* Выберем путь к БД по условию
lcPathFile = Alltrim(Iif(Upper(Alltrim(.Alias))=="PERSON", goApp.PathBdPerson, goApp.PathFile))
IF Not '\' $ .CursorSource
lc_Table = JUSTFNAME(.Database)
lc_Cursor = UPPER(.name)
.Database = lcPathFile+lc_Table
ELSE
lc_Table = JUSTFNAME(.CursorSource)
.CursorSource = lcPathFile+lc_Table
ENDIF
ENDIF
ENDWITH
ENDFOR
Ratings: 0 negative/0 positive
Re: Проблема с открытием таблиц в DE по заданному пути
akvvohinc

Сообщений: 4224
Откуда: Москва
Дата регистрации: 11.11.2008
Цитата:
И в чём его неправильность?
Не обращайте внимания на советы ИИ - ему ещё изучать Фокс и изучать.

Интересно, что у меня самого функция INSTR() есть.
Но она написана для других целей - возвращает .T., если хотя бы один символ первой строки входит во вторую:
? Instr('абв','ворон') && .T.

то есть используется для сокращения таких выражений:
? 'а' $ 'ворон' OR 'б' $ 'ворон' OR 'в' $ 'ворон'



Исправлено 1 раз(а). Последнее : akvvohinc, 15.03.23 15:37
Ratings: 0 negative/0 positive
Re: Проблема с открытием таблиц в DE по заданному пути
akvvohinc

Сообщений: 4224
Откуда: Москва
Дата регистрации: 11.11.2008
Каратаев
Написал же, что это только идея!
Ну, раз эту идею совместными усилиями удалось забраковать, то предлагаю ещё одну:
А нужны ли вам вообще переменные, использующиеся лишь один раз или не использующиеся вовсе?

Речь веду об этих двух:
lc_Table
lc_Cursor



Исправлено 1 раз(а). Последнее : akvvohinc, 15.03.23 15:50
Ratings: 0 negative/0 positive
Re: Проблема с открытием таблиц в DE по заданному пути
ssa

Сообщений: 13008
Откуда: Москва
Дата регистрации: 23.03.2005
Вот жеж настырный...
Такой вариант успокоит мятущуюся душу?
Local lcPathFile As String
For Each lo_Object as Cursor In Thisform.DataEnvironment.Objects
* Переназначим пути к БД в ДЕ
With lo_Object
If .BaseClass == 'Cursor'
* Выберем путь к БД по условию
lcPathFile = Alltrim(Iif(Upper(Alltrim(.Alias))=="PERSON", goApp.PathBdPerson, goApp.PathFile))
If Not '\' $ .CursorSource
.Database = Justfname(.Database) + Upper(.Name)
Else
.CursorSource = lcPathFile + Justfname(.CursorSource)
Endif
Endif
Endwith
Endfor


------------------
Лень - это неосознанная мудрость.
Ratings: 0 negative/0 positive
Re: Проблема с открытием таблиц в DE по заданному пути
akvvohinc

Сообщений: 4224
Откуда: Москва
Дата регистрации: 11.11.2008
Цитата:
Такой вариант успокоит мятущуюся душу?
Мне трудно сказать - он же отличается от предыдущего не только наличием переменных, но и по сути.
Ratings: 0 negative/0 positive
Re: Проблема с открытием таблиц в DE по заданному пути
of63

Сообщений: 25256
Откуда: Н.Новгород
Дата регистрации: 13.02.2008
akvvohinc
Цитата:
Такой вариант успокоит мятущуюся душу?
Мне трудно сказать - он же отличается от предыдущего не только наличием переменных, но и по сути.

() попроси доломай его, он умный, но, ттвой ум (?) важнее, от так с ними, монстрами/владельцами (?), можно найти "консенсус". не БоИсь вобщем, все наши

Сам "код, фоксовый", маловажен в этом разговоре. Просто , желательно, хорошо писать коды...



Исправлено 1 раз(а). Последнее : of63, 15.03.23 21:24
Ratings: 0 negative/0 positive
Re: Проблема с открытием таблиц в DE по заданному пути
Каратаев

Сообщений: 3977
Откуда: Алматы
Дата регистрации: 04.12.2001
Немного подправлю код:
Local lcPathFile As String
For Each lo_Object as Cursor In Thisform.DataEnvironment.Objects
* Переназначим пути к БД в ДЕ
With lo_Object
If .BaseClass == 'Cursor'
* Выберем путь к БД по условию
lcPathFile = Alltrim(Iif(Upper(Alltrim(.Alias))=="PERSON", goApp.PathBdPerson, goApp.PathFile))
If Not '\' $ .CursorSource
.Database = lcPathFile+Justfname(.Database)
Else
.CursorSource = lcPathFile + Justfname(.CursorSource)
Endif
Endif
Endwith
Endfor
В таком виде работает без ошибок.


------------------
Никогда не бывает настолько плохо, чтобы не могло быть еще хуже.
Ratings: 0 negative/0 positive
Re: Проблема с открытием таблиц в DE по заданному пути
Каратаев

Сообщений: 3977
Откуда: Алматы
Дата регистрации: 04.12.2001
akvvohinc
Каратаев
Написал же, что это только идея!
А нужны ли вам вообще переменные, использующиеся лишь один раз или не использующиеся вовсе?

Речь веду об этих двух:
lc_Table
lc_Cursor
И тут я задумался...


------------------
Никогда не бывает настолько плохо, чтобы не могло быть еще хуже.




Исправлено 2 раз(а). Последнее : Каратаев, 16.03.23 08:05
Ratings: 0 negative/0 positive
Re: Проблема с открытием таблиц в DE по заданному пути
akvvohinc

Сообщений: 4224
Откуда: Москва
Дата регистрации: 11.11.2008
Цитата:
В таком виде работает без ошибок.
Тем не менее, lo_Object всё равно лучше описать.
Ratings: 0 negative/0 positive
Re: Проблема с открытием таблиц в DE по заданному пути
ssa

Сообщений: 13008
Откуда: Москва
Дата регистрации: 23.03.2005
akvvohinc
Цитата:
В таком виде работает без ошибок.
Тем не менее, lo_Object всё равно лучше описать.
А он не описан?

------------------
Лень - это неосознанная мудрость.
Ratings: 0 negative/0 positive
Re: Проблема с открытием таблиц в DE по заданному пути
akvvohinc

Сообщений: 4224
Откуда: Москва
Дата регистрации: 11.11.2008
ssa
А он не описан?
В последнем Сашином варианте я этого не увидел.
Ratings: 0 negative/0 positive
Re: Проблема с открытием таблиц в DE по заданному пути
ssa

Сообщений: 13008
Откуда: Москва
Дата регистрации: 23.03.2005
akvvohinc
ssa
А он не описан?
В последнем Сашином варианте я этого не увидел.
А в моём?
For Each lo_Object as Cursor In Thisform.DataEnvironment.Objects


------------------
Лень - это неосознанная мудрость.
Ratings: 0 negative/0 positive
Re: Проблема с открытием таблиц в DE по заданному пути
akvvohinc

Сообщений: 4224
Откуда: Москва
Дата регистрации: 11.11.2008
ssa
А в моём?
Ну, поскольку твоё ничем не отличается от Сашиного, то и в твоём не увидел.
Ratings: 0 negative/0 positive
Re: Проблема с открытием таблиц в DE по заданному пути
Каратаев

Сообщений: 3977
Откуда: Алматы
Дата регистрации: 04.12.2001
akvvohinc
В последнем Сашином варианте я этого не увидел.
Насколько я понимаю, то остаётся опасение, что где-то, в другом коде вдруг появится свой lo_Object и это может привести к непредсказуемым результатам, так?
Ну вот если посмотреть несколько с иной точки зрения. Метод BeforeOpenTables срабатывает при загрузке формы... Даже если эта переменная и встретится в каком-то другом методе этой же формы, то lo_Object там будет переопределён уже с другими свойствами. При запуске дочерней формы, в её BeforeOpenTables lo_Object так же будет переопределён. Какое может возникнуть противоречие? Ведь нигде этот lo_Object не будет отрабатывать одновременно!
То есть, есть ли на самом деле смысл прописывать
LOCAL lcPathFile as String, lo_Object as Object
Для чего? :al:


------------------
Никогда не бывает настолько плохо, чтобы не могло быть еще хуже.
Ratings: 0 negative/0 positive
Re: Проблема с открытием таблиц в DE по заданному пути
akvvohinc

Сообщений: 4224
Откуда: Москва
Дата регистрации: 11.11.2008
Каратаев
Для чего?
Причин, по крайней мере, две (и об обеих я уже писал выше):

1) Если неописанная переменная не существует, то она становится PRIVATE по умолчанию.
Ты придумал ей имя с префиксом lo, намекая себе, что она локальная - налицо противоречие.
Приватные переменные видны ниже по стеку вызовов, то есть считая её локальной, есть шанс её испортить при вызове какой-то функции (метода) внутри области видимости этой переменной.

2) Если неописанная в методе переменная уже существует (определена где-то выше в стеке вызовов как PRIVATE или PUBLIC), то в данном методе ты портишь именно её - новая переменная в этом случае не появляется.

Каратаев
Даже если эта переменная и встретится в каком-то другом методе этой же формы, то lo_Object там будет переопределён уже с другими свойствами. При запуске дочерней формы, в её BeforeOpenTables lo_Object так же будет переопределён.
Ты используешь не совсем понятное мне понятие "переопределение" переменной.
Не описав эту переменную, ты не создаешь её, а используешь (портишь значение) одноименную переменную, если она существует и находится в области своей видимости в этом методе.
То же может случиться и с ней самой (раз она не LOCAL).

Поэтому надо говорить не о каком-то другом методе этой или любой другой формы или какой-то функции, а о любом коде, лежащем ниже в стеке вызовов.
И ты можешь легко это проверить, вызвав какой-то метод формы или любую функцию внутри своего FOR-цикла.
Добавь только в вызываемый код неописанную переменную lo_object и присвой ей какое-то значение.
И в сообщении от 15.03.23 14:24:55 я уже показывал аналогичный пример - ты его никак не прокомментировал.
forum.foxclub.ru



Исправлено 2 раз(а). Последнее : akvvohinc, 17.03.23 16:22
Ratings: 0 negative/0 positive
Re: Проблема с открытием таблиц в DE по заданному пути
PaulWist

Сообщений: 14621
Дата регистрации: 01.04.2004
Платон, ты мне друг, но истина дороже


------------------
Есть многое на свете, друг Горацио...
Что и не снилось нашим мудрецам.
(В.Шекспир Гамлет)
Ratings: 0 negative/0 positive
Re: Проблема с открытием таблиц в DE по заданному пути
akvvohinc

Сообщений: 4224
Откуда: Москва
Дата регистрации: 11.11.2008
Цитата:
Ведь нигде этот lo_Object не будет отрабатывать одновременно!
Ты собираешься следить и помнить о каждой своей неописанной переменной на протяжении всего срока жизни приложения?

Я и не писал, что твоя программа обязательно свалится от того, что ты не описал эту переменную.

И если ты и в дальнейшем собираешься следить за тем, чтобы эта переменная не вступила в противоречие с другой одноименной переменной, или просто будешь полагаться на авось (шансы при таком имени, действительно, невелики - это же не какой-нибудь X), то какие у меня могут быть возражения?.

Я лишь написал, что ты её не описал.
Разве не так?
Ratings: 0 negative/0 positive
Re: Проблема с открытием таблиц в DE по заданному пути
Каратаев

Сообщений: 3977
Откуда: Алматы
Дата регистрации: 04.12.2001
akvvohinc
Ты собираешься следить и помнить о каждой своей неописанной переменной на протяжении всего срока жизни приложения?
akvvohinc
И в сообщении от 15.03.23 14:24:55 я уже показывал аналогичный пример - ты его никак не прокомментировал.
А ведь ты прав! У меня была ситуация, схожая с показанным тобой примером. Там крутился цикл типа For i = 1 To.... В этом цикле вызывалась некая процедура, в которой тоже была переменная i... И я не сразу сообразил почему первый For выдаёт непонятные значения...
Но тут я понадеялся, что lo_Object использую только в BeforeOpenTables и наложения быть не должно... Но зачем такие риски? Это сейчас я помню, что, да как, а со временем забуду и вполне могу отступить от этого правила...
Так, что буду писать:
LOCAL lcPathFile as String, lo_Object as Object
PaulWist
Платон, ты мне друг, но истина дороже
Надеюсь, что в конце концов мы до этой истины добрались...



------------------
Никогда не бывает настолько плохо, чтобы не могло быть еще хуже.




Исправлено 1 раз(а). Последнее : Каратаев, 17.03.23 21:33
Ratings: 0 negative/0 positive


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

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

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