14.10.2008, 10:06 | #81 |
Axapta
|
Действительно непорядок. Во-первых, константы вместо макросов, во-вторых, можно было switch...case использовать, ну а в-третьих, вдруг война? А в военное время и таблица умножения поменяться может. А значит надо делать таблицу параметров.
PS. А в Вене действительно замечательно. Только недавно оттуда вернулся. |
|
14.10.2008, 10:25 | #82 |
Участник
|
Хм. Какие кейсы?
Там все в одну строчку кода можно свести. X++: numofpage = (factorForSpoiling ? (factorForSpoiling - 1) : factorForSpoiling) div 18 + 1;
__________________
Axapta v.3.0 sp5 kr2 |
|
14.10.2008, 10:27 | #83 |
Axapta
|
А ЧЮ где?
|
|
14.10.2008, 10:35 | #84 |
Участник
|
Ну, я в конце смайл, вроде бы, вставил
__________________
Axapta v.3.0 sp5 kr2 |
|
09.02.2009, 15:05 | #85 |
Участник
|
Интересный код обнаружился в Ax*-классах при доступе к полям-массивам: к примеру, в AxSalesTable, в методе dimensionElement() (для 3-ки) или же setDimensionElement() (для 4-ки и выше) вместо вроде бы очевидной конструкции
X++: fieldId2Ext(fieldnum(SalesTable, Dimension), _array) X++: new SysDictField(tablenum(SalesTable), fieldnum(SalesTable, Dimension), _array).id() |
|
08.01.2010, 13:59 | #86 |
Мрачный тип
|
Атавизьмы
Класс RAssetDisposalValue.
Безобразная передача параметров при инициализации экземпляров RAssetSumCalc дожила c 3-ки до DAX2009 X++: public server static RAssetAmount postValue(RAssetId _assetId, RAssetPostValue _postValue, RAssetAmount _assetAmount = 0, RAssetStandardId _assetStandardId, RAssetTransDate _assetTransDate = systemdateget()) { RAssetSumCalc rAssetSumTransThisYear, rAssetSumTransPriorYear, rAssetSumTransDate; RAssetTransDate prior_Years, this_Year; RAssetAmount assetAmount; ; this_Year = dateEndYr(systemdateget()); prior_Years = dateEndYr(prevyr(systemdateget())); rAssetSumTransThisYear = RAssetSumCalc_Trans::newAssetPeriod(RAssetTable::find(_assetId).AccountNum, _assetStandardId, this_Year, prior_Years);
__________________
Мы летаем, кружимся, нагоняем ужасы ... |
|
08.01.2010, 14:19 | #87 |
Участник
|
В 6ке им это придется пофиксить, так как компилироваться такое уже не будет
|
|
11.11.2010, 17:29 | #88 |
Banned
|
CustClassificationGroup
Если хочется от души посмеяться, рекомендую простенькую таблицу CustClassificationGroup из AX2009, особенно ее [нигде не используемые] методы find(), exist(). Из серии "как сделать в слове еще четыре ошибки"; так и представляется индус из Мумбая, которому дали тестовое задание - создать таблицу.
|
|
11.11.2010, 18:32 | #89 |
Участник
|
Нуу, работать то будет. Чуть странно с concurrencyModel, первый раз такое видел в коде. А так - ну, подумаешь, indentation плохой.
|
|
11.11.2010, 19:05 | #90 |
Модератор
|
Там все чуть более запущено чем просто проблемы с отступами - обрати внимание на первичный ключ на табличке
__________________
-ТСЯ или -ТЬСЯ ? |
|
12.11.2010, 01:53 | #91 |
Участник
|
Цитата:
Другое дело, что в этой табличке надо бы еще другой уникальный индекс создать. Но видимо табличка так часто используется, что пока не понадобилось |
|
12.11.2010, 02:15 | #92 |
Модератор
|
Цитата:
Цитата:
Другое дело, что в этой табличке надо бы еще другой уникальный индекс создать. Но видимо табличка так часто используется, что пока не понадобилось
Я в принципе догадываюсь, зачем эти неиспользуемые find() и exist() методы создавались - чтобы тупо пройти формальную проверку на их наличие. Вопрос в том, как такое сумели в SYS слой закоммитить и на кой ляд вводили разрекламированные юнит-тесты
__________________
-ТСЯ или -ТЬСЯ ? |
|
23.11.2010, 20:28 | #93 |
Участник
|
AX 2009 SP1 RU5, \Macros\SQLFormatting - вот и пользуйся после этого стандартными макросами
X++: #define.SQLfrom('FROM') #define.SQLOr('FROM') #define.SQLAnd('AND') #define.SQLNot('NOT') #define.SQLOrder('ORDER') #define.SQLBY('GROUP') |
|
|
За это сообщение автора поблагодарили: EVGL (1), Maximin (1), lev (1). |
23.11.2010, 22:29 | #94 |
Чайный пьяница
|
Цитата:
Сообщение от EVGL
X++: actorForSpoiling = prodTableRun.QtySched / InventTableRun.qtyPerLayer / prodTableRun.MEM_NumOfLanes; numofpage = 1; if (factorForSpoiling > 198) numofpage = 12; else if (factorForSpoiling > 180) numofpage = 11; else if (factorForSpoiling > 162) numofpage = 10; else if (factorForSpoiling > 144) numofpage = 9; else if (factorForSpoiling > 126) numofpage = 8; else if (factorForSpoiling > 108) numofpage = 7; else if (factorForSpoiling > 90) numofpage = 6; else if (factorForSpoiling > 72) numofpage = 5; else if (factorForSpoiling > 54) numofpage = 4; else if (factorForSpoiling > 36) numofpage = 3; else if (factorForSpoiling > 18) numofpage = 2;
__________________
Эмо разработчик, сначала пишу код, потом плачу над его несовершенством. Подписывайтесь на мой блог, twitter и YouTube канал. Пользуйтесь моим Ultimate Workflow Toolkit Последний раз редактировалось a33ik; 23.11.2010 в 22:46. |
|
23.11.2010, 23:01 | #95 |
Banned
|
Автор исходного кода не предполагал factorForSpoiling > 215. Речь идет, насколько я понимаю, о продольной резке полотна. По моим ощущениям больше 100 ножей не ставят.
|
|
23.11.2010, 23:03 | #96 |
Участник
|
Предположил, что расписывать на 13 и больше страниц коллега (или не коллега) EVGL уже не осилил
Но вы правы. Для полноты соответствия, надо еще проверку на больше 12 вставить. Можно и одной строкой PS Хотя, как выяснилось, речь шла вообще о другом
__________________
Axapta v.3.0 sp5 kr2 |
|
14.01.2011, 10:01 | #97 |
Мрачный тип
|
DAX2009, формы строк журналов ГК, переопределенные validate'ы и modified'ы - часто используются в анализе содержимого полей подобные конструкции :
X++: if (ledgerJournalTrans_ds.object(fieldnum(LedgerJournalTrans, AccountNum)).getValue()!="") X++: if (ledgerJournalTrans.AccountNum)
__________________
Мы летаем, кружимся, нагоняем ужасы ... Последний раз редактировалось TasmanianDevil; 14.01.2011 в 10:04. |
|
14.01.2011, 11:45 | #98 |
Участник
|
Однозначно индусский стиль
|
|
14.01.2011, 13:11 | #99 |
Мрачный тип
|
Там же, в LedgerJournalTransDaily на источнике данных LedgerJournalTrans ...
Метод active() постоянно вызывает метод setFurtherPostingProtection(), который меняет возможность редактирования 7 полей (тип счета и счет, тип корр.счета и коррсчет, суммы дебет/кредит и валюту) по факту заполненности полей FurtherPostingType и FurtherPostingRecId. Вот как это делает наш неизвестный герой: X++: void setFurtherPostingProtection() { int i; DictTable dictTable = new DictTable(ledgerJournalTrans.TableId); FormDataObject objectLedgerJournalTrans; boolean preventEdit; ; preventEdit = ledgerJournalTrans.FurtherPostingType && ledgerJournalTrans.FurtherPostingRecId; for (i = 1; i <= dictTable.fieldCnt(); i++) { objectLedgerJournalTrans = ledgerJournalTrans_ds.object(dictTable.fieldCnt2Id(i)); if (objectLedgerJournalTrans) { if (preventEdit) { switch (dictTable.fieldCnt2Id(i)) { case fieldnum(LedgerJournalTrans, AccountType), fieldnum(LedgerJournalTrans, AccountNum), fieldnum(LedgerJournalTrans, OffsetAccountType), fieldnum(LedgerJournalTrans, OffsetAccount), fieldnum(LedgerJournalTrans, AmountCurDebit), fieldnum(LedgerJournalTrans, AmountCurCredit), fieldnum(LedgerJournalTrans, CurrencyCode) : objectLedgerJournalTrans.allowEdit(false); break; default : objectLedgerJournalTrans.allowEdit(true); } } else { objectLedgerJournalTrans.allowEdit(true); } } } } Есть мнение, что за такое в таком месте - надо бить ... Наверное даже ногами и наверное даже по голове ...
__________________
Мы летаем, кружимся, нагоняем ужасы ... Последний раз редактировалось TasmanianDevil; 14.01.2011 в 13:17. |
|
|
За это сообщение автора поблагодарили: fed (3), Vadik (5). |
14.01.2011, 13:26 | #100 |
Модератор
|
И кто ж, как и на что их (вне привязки к национальности - скажем, "этих людей") в таком случае тестирует при найме (помню ты рассказывал как валят кандидатов не умеющих генерировать качественный (с) код). И через скольких (в среднем) людей проходит код перед тем как попадет в релиз? Если конечно это не секрет
P.S. Я не ерничаю, просто наблюдаю какой-то непонятный процесс (вернее, два - набор персонала и процесс проверки кода при переносе в релиз) и хочется разобраться
__________________
-ТСЯ или -ТЬСЯ ? |
|