Всем добрый день!

Вот написал я программку на VB6 под WIN98. Скомпилировал в .exe - всё OK.
Теперь несу екзешник на другую машину, запускаю там - фиг вам!- показывает Run time Error 713: -"на этой машине не зарегистрирован класс, требуется файл msstdfmt.dll"
Нахожу на своей машине этот файл, несу туда же, сую, - никакого эффекта! :((((( Все равно та же ошибка. Как побороть такую ситуацию?

В общем-то, проблемы переносимости у меня были и раньше: то Msvbvm60 не хватает, то какого-нибудь .ocx, но они, в общем, легко решались добавлением требуемого файла, а теперь вот капитально споткнулся :((((

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

Цитата

на этой машине не зарегистрирован класс, требуется файл msstdfmt.dll... этот файл, несу туда же, сую, - никакого эффекта... Как побороть....

"Пуск"->"Выполнить", в окошке вводишь: regsvr32.exe путь_к_dll\msstdfmt.dll
Вообще, правильно было бы использовать Package & Deployment Wizard для создания дистрибутива, в котором будут присутствовать все необходимые для работы проги компоненты и при установке они будут автоматически регистрироваться в системе.

Цитата

есть ли способ заранее узнать, какие именно внешние файлы требует скомпилированный экзешник

На счет Msvbvm60 ты уже в курсе, посмотреть же остальные компоненты, которые ты сам подключил в проект можно кликнув менюшки "Проект"->"Ссылки"; "Проект"->"Компоненты".

Это сообщение отредактировал(а) bom - 13.8.2004, 20:27

Спасибо, bom!
------------------------
Вот про regsvr я не знал! А про создание дистрибутива мне говорили, только не люблю я их, - виндовых инсталляшек. Назаменяют кучу файлов, а потом начинает глючить система... Так что не хотелось бы пользователя грузить тем же. Лучче я громоздкий исходник сделаю, но пусть, за то, экзешник просто работает, ничего не изменяя на машине пользователя, не вписывая в системный реестр мусора и прочее подобное... (Идеал, конечно,- а идеалов нету на свете)))))
==
Вот при таком подходе: этот самый "класс" он от чего возникает, не скажешь ли? Одну прогу писал - такой ошибки не было. Вторую - на той же машине, тем же VB, одними стандартными(!) контролами, теми же приемами программирования - и этот "класс" почему-то появился... Я конечно, методом исключения, найду, что именно в исходнике за него ответственно, тока много времени понадобится: VB дома, а проверяю - несу на работу (на самой слабой машине), т.е. сутки - на каждый "цикл".

А про .ocx, мне тут сказали про Fusion, которая их в экзешник может запихнуть. Но я не попробовал еще.



Всем спасибо,
Эд

Fusion то в ехе'шник их засунит, но потом точно так же вывалит тебе .ocx'ы в системную папку...
Читай тут:
http://forum.vingrad.ru/index.php?showtopic=21194

Сенк ю вери мачч!!!!!
Спасибо что предупредил! Значительно лучше запаковать в зип вместе с .ocx, и пользователь просто распаковывает всё в один (свой!) каталог. А то сделали из \SYSTEM свалку.

ЗЫ
Прежний твой пост внимательно прочитал. Спасибо за информацию

Эд, про регистрацию ActiveX-ов не забывай.
Или сделай регистрацию из кода.

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

А вот к слову: есть dllка, которая управляет устройством. Но без описания (просто от одной проги).
Как узнать, какие у нее имена параметров, свойств? Чего она хочет при запуске в VB?
Там внутри у нее нет имен, чтоб выцарапать их?

Эд

а dllка это ActiveX или простая?

Простая. Она только к устройству обращается. А прога была на VB5 писана. Мне не нравится. (Думаю свою попробовать.)

Эд

Цитата

А про создание дистрибутива мне говорили, только не люблю я их, - виндовых инсталляшек

Тогда надо самому позаботиться что бы прога работала на других машинах, как альтернативу инсталлятору можно попробовать использовать самораспаковывающийся архив со всеми необходимыми компонентами, которые будут извлечены в папку с прогой.
Заметил одну особенность, если не прав, поправьте, - "родные" компоненты при старте программы ищутся сначала в ее папке, потом в системной, когда находятся, то если не зарегистрированны, регистрируются автоматически. "Не родные" - требуется зарегистрировать самому, можно прописать процедуру регистрации в процедуре обработки ошибки, т. е. если при запуске проги инициируется ошибка 713, то в обработке этой ошибки, как советует boevik, сделать регистрацию "не родной" dll и возвратиться обратно. На всякий случай чтоб прога не зациклилась, если регистрация не произойдет, можно добавить счетчик, ограничивающий количество попыток скажем 2 и выгружающим прогу с сообщением о невозможности регистрации компонента.

Цитата

этот самый "класс" он от чего возникает, не скажешь ли?

На эту dll где то есть ссылка в проекте. Найди ее и удали если она не нужна и попала в туда случайно методом copy - paste

Цитата

Я конечно, методом исключения, найду, что именно в исходнике за него ответственно, тока много времени понадобится: VB дома, а проверяю - несу на работу (на самой слабой машине), т.е. сутки - на каждый "цикл".

Предлагаю уменьшить цикл, разрегистрировав msstdfmt.dll на домашней машине командой
regsvr32.exe /u путь_к_dll\msstdfmt.dll

Всем спасибо, друзья!

"Цикл" я действительно уменьшил, просто временно перенося msstdfmt в другое место, и обнаружил вот что.

Сперва я думал, что причина в примененном новом (для меня ) подходе - создании массивов управлений. Я попытался обойтись без этого (переключая подпрограммы при помощи Select). Кто понимает, про что я - пригладьте вставшие дыбом волосы ну ладно вам ржать-то, надо-ж было проверить.
И - ничего подобного! Дело оказалось не в этом, а в том, то для одного текстового поля было установлено свойство DataFormat (по умолчанию оно пустое). А я ставил ему number, вот и возникал этот "класс".

Всё уже исправил, так что на этот раз соблюсти свои принципы мне удалось: прога без всякой инсталляции, одним файлом (не считая msvbvm60, это же VB все-таки, что поделаешь).

Цитата

Тогда надо самому позаботиться что бы прога работала на других машинах

Ага! Вот я и забочусь... Да, компоненты ищутся сначало около экзешника., на этом я и основываюсь; всё действительно можно распаковать из архива в один каталог. А касательно специальной регистрации - это уже плохо, чем меньше прога меняет, тем лучше,
так что от этого пытаюсь уходить. Вот в этой, например, удалось совсем не использовать дополнительных .ocx, все сделал вручную, хотя должен признать, что они все-таки значительно облегчали жизнь.


Пока; всем удачи и СПАСИБО!!!

Эд

Я думаю, что ты просто до потолка будешь прыгать когда начнешь программировать на Си. Там можно все статически залинковать и будет у тебя один (распухший правда ) exe.

Си - хороший язык... Но я к Бейсику привык, вот беда Пробовал на Си, даже, вроде получалось че-то, все-таки опять возвратился на круги своя...

Рожденный ползать, летать не може

Твоя "стеганография" мне понравилась (хотя сам метод, как полагают, изобретен Френсисом Бэконом, 16 век).
А кстати, не в курсе,- правда ли что PGP конкретно сломали?

Эд

Очень даже может!!!
Я тоже долгое время не мог с бейсика на другой язык перейти, но потом поюзал масм32... понравилось...начал разбираться, маленькие программы на асме писать(большие и серьезные пока еще на бейсике...), а через некоторое время понял в чем сила реальных классов(дело в том что в ВБ классы до седьмой версии - как в си структуры) начал на Сях прогать...теперь на бейсике (даже .Net) не могу нормально прогать(точнее могу, но привык уже к Си)

PS: Конечно же все поняли,что когда я говорил про С то имел ввиду С++
PPS:А то подумают, что идиот какой-то(в С классов нет).

Так что юзай Си++!