Божья_коровка
Совет - НЕ ПРИНЯТ!

Дело личное. А вот капс в данном случае свидетельствует о повышении тона.

Божья_коровка
Я привела в более менее работающий вид....
PS. Ладно уговорил, говори что за 3 ошибки и что исправить, чтобы ничего не поломать. Я только sele с use убрала потому что тоже не понимаю зачем они нужны.

Первая ошибка очевидна - если в пути PathToSpr будут пробелы, это г*нецо с макро рухнет с весёлым гиканьем.
Вторая - зависит от того что может оказаться в переменной p_obl - если там может оказаться ОДНОСИМВОЛЬНОЕ значение, например "1" а не "1 " - то запрос при штатной установке SET ANSI OFF выберет вовсе не то что подразумевал автор - например в результат выборки попадут элементы "12","19" или там "1А". Конечно, можно "урегулировать" вопрос выставив где-то ранее SET ANSI ON, но как по мне так проще и логичнее прямо в запросе писать == вместо =

Одной потенциальной ошибки не видно, т.к. не ясно что (точнее КАК) делает процедура OBL - конечно если это процедура, а не такой "мега-очевидный" способ обращения к массиву Возможно автор не знал что к элементам массива можно обращаться заключая индексы в квадратные скобки - чтобы сразу было видно что это не вызов функции (хотя внутри фокса, к сожалению, эти две совершенно разные операции не различимы - если есть одноименный массив, то будет обращение к массиву, независимо от того какие скобки прописывать в выражении).
В любом случае стоит посмотреть не логичнее ли там использовать ListIndex (если вдруг источник комбо может сортироваться, или это не массив а "вручную добавленные" элементы).

Из "корявостей" - приватные или вообще глобальные массивы - тот же regs, возможно и obl - если это таки массив. Макро, там где макро вообще не нужно. Вбивание в текст запроса "литерала" при помощи макро и этого самого ...'"+LEFT(p_obl,2)+"'" вместо простого как грабли использования ПРОСТО значения-параметра - что открывает путь к sql-инъекции, да и просто "тупым" ошибкам - например если внутри значения p_obl окажется одинарная кавычка...

sele regs + use просто закрывает курсор. И заменяется на аналогичный, но НЕ вызывающий ошибок даже если открытого курсора нет USE IN SELECT("regs"). Хотя сам вопрос целесообразности постоянного "закрывания" этой самой таблицы - при том что она, очевидно, заново будет открываться при изменении значения в "верхнем" комбо - это очень интересный вопрос... Я бы по крайней мере не стал закрывать этот курсор...

В общем остаётся только посочувствовать тебе с доставшимся "в наследство" кодом...

sphinx

Божья_коровка
Совет - НЕ ПРИНЯТ!

Дело личное. А вот капс в данном случае свидетельствует о повышении тона.

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

Божья_коровка
А вот теперь можно поговорить и о красоте

Присоединяюсь к сочувствию

Может пригодится.
Был огромный чужой проект.
Который дали, на тему доработки отдельных модулей.
Все очень жестко завязано.
Как вы пишете, в одном месте меняешь, в другом не работает(
Все сплошь глобальное(
Намаявшись с ошибками, взялся изучать интерфейс (взаимодействие) каждой формы с остальными.
(Вся логика в основном в формах, что то в огромных прг.)

И дальше, старался соблюдать этот интерфейс.
Были входные глобальные, я их входные значения, присваивал своим свойствам.
Делал все нужные операции, и из своих свойств, возвращал в глобальные

Ужас конечно.
Но если на долго, то никуда не денешься, придется разбираться(

Игорь, все замечания приняла к сведению!

Это конечно оффтоп, но по моему мнению идеального кода не бывает, как разработчик привык писать так и пишет,это называется стиль, и тут уж мало что поделать можно. Разбираясь в чужом я не спешу кого то ругать, это рутина и это тоже работа, кропотливая работа, требующая внимания и времени. Как говорит Оффа при "залазеньи" в чужие дебри, нужно стараться не ломать работающих конструкций, они годами работали и пусть работают, нужно просто подстроиться. И я разделяю это мнение.

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





Исправлено 2 раз(а). Последнее : Божья_коровка, 02.07.17 21:25

Коровка скоро составит серьезную конкуренцию Оффе в философии.

Думаю никто не пишет, для кого то.
Главное что бы через 10 лет, сам мог легко разобраться.
В том что ты привела, автор через месяц не разберется.
И никаких идеальных кодов.
Есть "выстраданые" прпвила, которые описаны во множестве трудов.
Но им просто не верят, и не следуют. И как результат...

Ну в приведенном то коде "разобраться" немудрено, и даже "не автору" - а вот отследить все его взаимосвязи и взаимоувязки (особенно если это РЕАЛЬНО public массивы используются) - вот это да, это проблема. Жаль что не все понимают это и продолжают использовать тонны public или private переменных... И простой и с виду "безобидный" кусочек кода вырастает в итоге в огроменный геморрой для сопровождения. Так что тезис "это называется стиль" глубоко ошибочен. Это называется непонимание основ и лячканье г*нокода - будем уж честны в формулировках...