Access violation at address... поможите ламеру.

vagabond 04.06.2004 - 12:55 | Проект такой-то вызвал исключение класса EAccessViolation с сообщением 'Access violation at address 0056E147 in module 'project1.exe'. Read of address 000002F8. Процесс остановлен.... . вот такая вот байда происходит при вызове TfrReport.ShowReport (FastReport). уж чего только ни делал. . Подскажите знающие люди, существует ли какой-либо общепринятый действенный метод выяснения причины вот таких вот ошибок, а то "акцесс виолэйшн" это конечно круто и все такое, но где тут собака порылась - неясно. . .зы со стороны Borland подобные сообщения - свинство, по-моему.
vagabond 1 - 04.06.2004 - 12:56 | Delphi 7, блин.
VaS 2 - 04.06.2004 - 13:04 | 1. Аккуратней с Борландом. 2. ShowReport() не является классовым методом.
vagabond 3 - 04.06.2004 - 13:36 | TfrReport.ShowReport(FastReport) - имелось ввиду что используется FastReport 2.4 и вызывается ... TfrReport.ShowReport; ...
vagabond 4 - 04.06.2004 - 13:38 | собственно, пофиг этот репорт. интересно, как вообще выясняются причины таких ошибок, неужто сидением и гаданием на кофе и проверкой всего подряд с самого начала.
archimag 5 - 04.06.2004 - 13:53 | Говорят, что некоторые люди в таких ситуация используют отладчик :-). Конечно, со стороны Borlanda полное свинство сообщать такое, лучше бы он сам ошибки исправил :))
ИгорьК 6 - 04.06.2004 - 13:57 | вообще-то методы вызываются для объектов, а не для классов. типа так: ... var MyReport: TfrReport; ... begin MyReport:=TfrReport.Create; MyReport.ShowReport; end;
Тупой ламер 7 - 04.06.2004 - 13:59 | вы явно не работали VC, если процесс отладки на Delphi вас так ужасает :-) вопль в принципе правильный, а что вы можете предложить по сути? чтобы Access Violation давал больше информации о том, на чём он споткнулся, необходимо менять сам принцип организации работы с указателями на объекты, причём для ОС менять. И хороших предложений лично я не знаю. Иначе любые решения на уровне компилятора будут всего лишь надстройкой.
vagabond 8 - 04.06.2004 - 14:08 | 2 ИгорьК не, ну я ламер конечно, но не настолько же :) описАлся просто! 2 Тупой ламер - в VC не работал. - вобщем примерно понятно. ну чтож. спасибо.
VaS 9 - 04.06.2004 - 14:31 | Нда, с классовыми методами я неосторожно - не та аудитория :) 6 нагляднее получилось... 7: Указатели на делфийские объекты на уровне ОС?? Поподробнее можно? 0: Во время отладки: Search -> Find Error... и вводим 0056E147.
Тупой ламер 10 - 04.06.2004 - 14:39 | VaS, я имел ввиду вообще парадигму ОС касаемо объектов (не Delphi именно). Win32 ни в коем случае не объектно-ориентированная ОС, потому мы и имеем AC в любом шаге в сторону. Если бы все заимоотношения с OC на любом уровне детализации/доступа строились с использованием объектов с обязательным механизмом интроспекции и указатели были бы умнее (а мысли у многих ведущих разработчиков в этом направлении есть), то само понятие висячего указателя, который ни на что не указывает, или указывает не туда, исчезло бы.
VaS 11 - 04.06.2004 - 14:42 | Тупой ламер: .NET?
Тупой ламер 12 - 04.06.2004 - 14:42 | очепятка: AC = AV (access violation)
vagabond 13 - 04.06.2004 - 14:46 | - я не знаю общеизвестных определений для оочень многих понятий. хотя с самими понятиями знаком. просто все что знаю - знаю сам по хелпам и книжкам, никто не учил и не тыкал носом, с чего начинать и что в первую очередь... теперь я знаю, что это называется "классовый" метод. - FindError нашел мне место то место в коде, где происходит ошибка. Оказалось, это место в глубинах модуля FR_Class. спасибо всем. пошел я тупить дальше..
Тупой ламер 14 - 04.06.2004 - 14:50 | я слабо знаком с .NET технологией. точнее, не так... точнее, в своё время я увидел в реализации .NET только зачатки того, чего я хотел бы видеть в системе, потому пока и не спешу переходить. Ничего там принципиально нового. imho, сыро у них всё ещё, многие вещи только решаются... да и строится пока на старых костях старых систем :-) конечно, Винер в своё время показал, что и из ненадёжных кубиков можно строить надёжные пирамиды, но - как раз подобного в .NET я не вижу. Хотя, может, просто у меня времени нет разобраться как следует.
Тупой ламер 15 - 04.06.2004 - 14:56 | 2 vagabond: а стек вызовов на момент ошибки не даёт никаких мыслей? как правило, в большинстве случаев это самый простой метод найти грабли с AV.
vagabond 16 - 04.06.2004 - 15:52 | TfrBandView.Draw($12EEAC) TfrPages.RefreshObjects TfrReport.PrepareReport TfrReport.ShowReport TfrmRegister.btnOKClick(???) TfrmMain.actRegisterExecute(???) project1 ------------------------------------- я правильно понял, что ошибка возникает при вызове TfrBandView.Draw
vagabond 17 - 04.06.2004 - 15:53 | по ходу report.frf кривой. Хотя чему бы там...
vagabond 18 - 04.06.2004 - 16:03 | внатуре, йоптить. Кривой был банд "Report title". Хотя как_именно кривой - неизвестно, т.к. его уже нет.. грохнул сгоряча блин. и все заработало! - Огромное спасибо Тупому ламеру от просто ламера! (за наставление смотреть в стек вызовов)
Sabrian 19 - 05.06.2004 - 04:15 | И правильно что грохнул!!! Вообще любой код не создаваемый средой должен быть удален нафиг! Так как, только сгенеренный код Delphi отлаживает автоматически, и подобного сообщения ты не увидишь никогда. Не уподобляйся мазохистам, не используй всякие там глючные Fastreport и.т.д , иначе гадание на кофейной гуще будет твоим повседневным занятем. P.S. На самом деле ошибка была глубже - где-то в процедере ErrorProc. P.P.S А Borland - он и вправду глючный
Тупой ламер 20 - 05.06.2004 - 15:56 | Я бы не стал так категорично относительно сторонних компонент. Они разные бывают. А FastReport в этом плане достаточно стабилен - просто нужно знать его тонкости и правила работы с ним. Не уподобляйтейсь невеждам, кричащим must die, не разобравшись на собственной шкуре, не по вашей ли причине он глючит? Вы уверены в соблюдении протокола вызова? В правильности параметров? А ещё есть ограничения по типам, их объёмах и многое другое. Залезьте в исходники (благо они есть, и полные), и посмотрите, что именно не так? И, в конце-концов, вы хелп читали по компоненту? Кричать "глюк" можно только тогда, когда прошёл по всей цепочке исходников до ошибки и, да, понял, что глюк у него, а не у тебя. Я так поступаю всегда и, знаете, в 99,9% случаев - глючу я, а не компонент. Это сложно, и трудоёмко, но результат - вы не только решаете проблему, но ещё и чуть умнее в общем плане. Просто я сам пишу компоненты, и, знаете, написание компонент - это гораздо более сложная вещь, чем написание класса под нужды здесь-и-сейчас. На порядок более сложная при тех же требованиях по функциональности. А если кому не хочется использовать компоненты - так вперёд! Стандартный набор common controls - и за орденами!
VaS 21 - 05.06.2004 - 21:25 | Тупой ламер: Мне кажется, не стоит обращать внимание на заявления типа 19. Тем более, оно похоже на шутку. По поводу универсальных библиотек классов согласен - дело сложное, причем настолько, что не стоит делать некий класс применимым где угодно с расчетом на будущее - это будущее очень часто не наступает.
Sabrian 22 - 06.06.2004 - 02:09 | Оно не похоже - оно и есть! :)
VaS 23 - 07.06.2004 - 17:15 | Тупой ламер: Есть деловой разговор. Если можешь выкроить немного времени, напиши на мыло vaskir собака mail.ru.

>>