VISUAL BASIC 6.0 y DLL's: ¡¡ Ayuda !!
Domingo López
tenía en Visual Basic 4.0 a Visual Basic 6.0. Después de algunos ajustes
conseguí cargar, compilar y ejecutar dicha aplicación en el nuevo entorno
de desarrollo. Esta aplicación utiliza además un gran número de DLL's
externas programadas en Visual C++ 6.0.
El problema es que cuando me pongo a depurar mi aplicación dentro del
entorno de desarrollo de Visual Basic 6.0, se produce un error en la misma
motivado
por una de las llamadas a mis propias DLL's, consistente en que la
aplicación no
encuentra dichas DLL's, o mejor dicho, no puede cargarlas. Sin embargo,
antes las cargaba perfectamente. Este error NO se me reproduce si trabajo
con el
ejecutable de la aplicación, sin entorno de desarrollo.
Me gustaría saber si alguien está teniendo problemas parecidos con Visual
Basic 6.0, y si ha encontrado soluciones a los mismos. He visto en el MSDN
que Visual
Basic 6.0 viene con un error (que se corrige en los Service Pack)
consistente en que
no puede abrir más de ocho DLL COM simultaneamente. El caso es que
instalándome el
Service Pack que lo corrige sigo teniendo el mismo problema, ya que además
las DLL's
que yo utilizo son propias de la aplicación.
Además también me gustaría saber si alguien ha notado que sus aplicaciones
en Visual Basic 6.0 en ocasiones tardan mucho tiempo en refrescarse porque
se quedan en un
estado en el que retienen eventos, y luego los sirven todos de golpe.
Si alguien tiene cualquier información sobre estos temas, me sería de gran
ayuda que me la transmitiera. Muchas gracias por adelantado y un saludo,
Domingo López
dlo...@vtools.es
DevTeam
> El problema es que cuando me pongo a depurar mi aplicación dentro del
>entorno de desarrollo de Visual Basic 6.0, se produce un error en la misma
>motivado
>por una de las llamadas a mis propias DLL's
Esto muchas veces se debe a que, la depuración via IDE (entorno de
desarrollo de VB) es muy inestable cuando se trabaja con API's (que creo
este es el caso, ya que no especificaste si son objetos ATL compilados en
C++, o una simple DLL)
Sobre este mismo problema, puede deberse a que, si esta misma DLL era
manejada por VB4, tal vez esté en 16bits, a lo cual VB6 no responde
correctamente.
> Además también me gustaría saber si alguien ha notado que sus
aplicaciones
>en Visual Basic 6.0 en ocasiones tardan mucho tiempo en refrescarse porque
>se quedan en un
>estado en el que retienen eventos, y luego los sirven todos de golpe.
Esto puede ser causado por que, en procesos largos, (bucles for...next,
do...loop) no hay ninguna llamada a DoEvents, que se encarga de procesar los
eventos (diferente de Sleep API, ya que DoEvents se encarga de hacer otras
cosas)
Espero est sea de ayuda,
Saludos
DevTeam
MMedia Systems
Domingo López wrote in message <7kb83m$niu$1...@talia.mad.ttd.net>...
Domingo López
DevTeam wrote in message <#r#gelRu#GA....@cppssbbsa02.microsoft.com>...
>Domingo,
>
>> El problema es que cuando me pongo a depurar mi aplicación dentro del
>>entorno de desarrollo de Visual Basic 6.0, se produce un error en la misma
>>motivado
>>por una de las llamadas a mis propias DLL's
>
>Esto muchas veces se debe a que, la depuración via IDE (entorno de
>desarrollo de VB) es muy inestable cuando se trabaja con API's (que creo
>este es el caso, ya que no especificaste si son objetos ATL compilados en
>C++, o una simple DLL)
>Sobre este mismo problema, puede deberse a que, si esta misma DLL era
>manejada por VB4, tal vez esté en 16bits, a lo cual VB6 no responde
>correctamente.
>
La DLL a la que estoy haciendo la llamada está desarrollada por nosotros,
en Microsoft Visual C++ 6.0 y es de 32 bits. Cuando trabajábamos con
Visual Basic 4.0, las DLL's estaban compiladas en Visual C++ 5.0, y no
tuvimos
este problema en ningún momento.
Además, en alguna de las múltiples pruebas que estamos haciendo,
conseguimos
que en determinados momentos este error no se produzca en dicha DLL, pero
entonces, salta en otra, que ni siquiera es nuestra (en particular, es una
DLL
de un control de Crescend, de 32 bits también).
Lo que quería expresaros es que no parece ir el problema por ese lado. Lo
malo es
que no conseguimos encontrar de dónde cojea. En lo que os doy la razón es en
que la
depuración vía IDE es muy inestable. Si con lo que os he contado, me podéis
decir
más cosas, os lo agradecería muchísimo (estamos ya un poco hartos y
desesperados).
>
>> Además también me gustaría saber si alguien ha notado que sus
>aplicaciones
>>en Visual Basic 6.0 en ocasiones tardan mucho tiempo en refrescarse porque
>>se quedan en un
>>estado en el que retienen eventos, y luego los sirven todos de golpe.
>
>Esto puede ser causado por que, en procesos largos, (bucles for...next,
>do...loop) no hay ninguna llamada a DoEvents, que se encarga de procesar
los
>eventos (diferente de Sleep API, ya que DoEvents se encarga de hacer otras
>cosas)
>
No lo veo muy claro. El código es el mismo que en Visual Basic 4.0 y allí
no teníamos
esos problemas. Y si es así, ¿porqué hacen falta esas llamadas a DoEvents en
Visual Basic 6.0?
>
>Espero est sea de ayuda,
>
>Saludos
>
>DevTeam
>MMedia Systems
>
Pues saludos, gracias por vuestra ayuda, y si sabéis cualquier otra cosa
que se
nos esté pasando por alto, no dudéis en contárnoslo a la mayor brevedad
posible.
Gracias por adelantado.
Domingo.