Что сделать чтобы exe файл работал на другом компьютере, где не установлен Visual Basic и не установлен Microsoft Office.

даёт ошибку, потому что нету файла msstdfrm.dll 

Ну, возьми этот файл и скопируй его в system32...

В чём проблема-то? 

ты меня не понял

exe файл сделан в Visual Basic и использует библиотеки из Visual Basic.
имена эти библиотеки он и не найдет. я ставил их возле exe файле но толька msstdfrm.dll не работает

я хочу копировать все на флэшке и потом чтоби использовать на любой комьютере 

msstdfrm.dll  положи в system32.

Если будет дальше артачиться, то напиши.
Будем думать... 

для этого нужна искать где установлен Видовс а потом скопировать с флашке этот файл

а использовать его сразу с флэшке не возможна?  

Это сообщение отредактировал(а) hhhhhh - 20.7.2006, 14:40

Хм...
Ставить прогу будешь сам ручками, или будешь писать программу-установщик?  
Если ставить ручками, то неужели сложно определить, где стоит винда?   

1) А какие фалы кроме msvbvm60.dll нужно копировать в систем-рт на компе без бейсика?
2) Не могли бы кто-нибудь привести пример батника (*.bat) который сам копирует фалы в систем-рут? Очень было бы удобно. 

Посмотри здесь, здесь,  и здесь.

 

 

Действительно, 

регистрирует нужный файл в системе...

И что?  
Мы, по-моему, несколько о разном говорим...
Чего-то я в этой жизни не понимаю.  
 

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

hhhhhh, а то, что ты приводишь вобще не имеет отношения к моему вопросу  

hhhhhh:
Я давно столкнулся с этим, и пришел к следующему мнению: если хочешь, чтобы скомпилированная прога была завершенным экзешником, не требующим для себя ничего, кроме Msvbvm, не следует использовать компоненты управлений, а всё делать "в ручную".
Подключение в проекте любого компонента приведет к тому, что экзешник начнет искать какую-нибудь внешнюю .dll или .ocx.
Еще у меня был случай - выставил свойство DataFormat для TextBox - и на другой машине прога начала писать "не зарегистрирован класс". Так что, пользуйтесь только теми свойствами, предназначение которых Вам известны и проверены, остальное оставлять по умолчанию.

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



Создаете модуль и вставляете в него этот код без изменений. Это позволит пользоваться в проге тремя функциями API.
Вызываются они в программе следующим образом (пример):

Fname$ = OpenDialog$("Открыть файл", "Тексты" + vbNullChar + "*.txt" + vbNullChar + "Все файлы" + vbNullChar + "*.*" + vbNullChar)
Вызывает окно открытия файлов.

Fname$ = SaveDialog$("Сохранить", "Тексты" + vbNullChar + "*.txt" + vbNullChar + "Все файлы" + vbNullChar + "*.*" + vbNullChar)
Вызывает окно сохранения файлов.

Обе возвращают строку: имя выбранного файла или пустую строку в случае отмены. Особо отмечаю, что эти функции сами НЕ ОТКРЫВАЮТ файлов, а только выдают вам имя. Они предназначены лишь для позиционирования по древу каталогов. Получив имя выбранного файла, откройте его бейсиковой функцией Open, как обычно.

  Третья функция предназначена для задержки выполнения программы. Вызывается:
Sleep 500
(задержка на 0.5 сек, к примеру). 
Особое достоинство этой функции в том, что пока ваша прога приостановлена ею, ресурсы высвобождаются для выполнения других задач, запущенных на машине. Если же Вы сделали бы, например, какой-нибудь здоровенный пустой цикл, он затребовал бы на свое выполнение максимально доступный ресурс и тормознул бы этим всю машину.

Я думаю, что именно эти три функции - единственный случай, когда применение API и полезно, и оправдано, несмотря на их громоздкость.