Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Développement Développement Visual Basic lancerapplication

lancerapplication

15 réponses
Avatar
lou
bonjour
je voudrais lancer une base access 2000 a partir d une application vb

j ai essayé le fameux shell mais ça ne marche qu avec des .exe(appartament)

mon programme acces 2000 s appelle FRONT.mde
ma question est comment lancer un programme qui n est pas un exe a partir de
vb
merci de votre aide
Signaler un problème avec ce contenu

5 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
Jean-marc
François Picalausa wrote:
Hello,

<inline>

Dans le cas de FORMAT_MESSAGE_ALLOCATE_BUFFER, &HFFFF& serait la
taille du buffer minimum à allouer ; je pense que 0 serait tout à fait
suffisant, mais y a peut-être une raison que j'ai loupée?

<private joke>
Peut-être que Jean-Marc t'as trop converti à la philosophie "on en est
pas à quelques Ko de mémoire près" ? :-P
</private joke>




Private Sub Command1_Click()

Dim buf As String
Dim s As String

buf = Space$(1000000)

s = "Muhahahahahahaha"

Mid$(buf, 1, Len(s)) = s

MsgBox buf

End Sub




--
Jean-marc Noury (jean_marc_n2)
Microsoft MVP - Visual Basic
FAQ VB: http://faq.vb.free.fr/
mailto: remove '_no_spam_' ;
Avatar
Jacques93
François Picalausa a écrit :
Hello,

<inline>

On Jan 20, 2:19 pm, Jacques93 wrote:
Bonjour François Picalausa,
François Picalausa a écrit :

On Jan 20, 11:29 am, Jacques93 wrote:


<snip>

Le top du top serait d'appeler FormatMessage avec
FORMAT_MESSAGE_ALLOCATE_BUFFER pour être certain de ne pas avoir un
buffer trop court. Ca doit pouvoir se faire par CopyMemory...


Effectivement le code que j'ai posté est risqué de ce côté là, et peut
planter l'application au lieu d'afficher un gentil message, ce qui est
tout de même bêta. Je pense que ce code devrait être plus "propre" :



<snip le début du code>
Format = FORMAT_MESSAGE_FROM_SYSTEM Or _
FORMAT_MESSAGE_ALLOCATE_BUFFER Or _
FORMAT_MESSAGE_MAX_WIDTH_MASK



Je ne suis pas certain de comprendre pourquoi tu as choisi d'utiliser
un FORMAT_MESSAGE_MAX_WIDTH_MASK ? Si des linebreaks sont présents à
l'origine, on peut supposer qu'ils sont utiles, mais j'ai peut-être
mal compris l'intention?



J'ai surtout du mal a comprendre les nuances de la doc MSDN concernant
l'API FormatMessage:

<Citation>
The low-order byte of dwFlags can specify the maximum width of a
formatted output line. The following are possible values of the
low-order byte
</Citation>

On peut donc se dire que c'est la largeur maxi d'une ligne, non ?
Mais :

<Re-Citation>
If the low-order byte is a nonzero value other than
FORMAT_MESSAGE_MAX_WIDTH_MASK, it specifies the maximum number of
characters in an output line. The function ignores regular line breaks
in the message definition text. The function never splits a string
delimited by white space across a line break. The function stores
hard-coded line breaks in the message definition text into the output
buffer. Hard-coded line breaks are coded with the %n escape sequence.
</Re-Citation>

est un peu (nettement) moins clair pour moi, entre la constante (0xFF)
et d'autres valeurs, 0xFE ou 0x100 par exemple, y a t-il une différence
majeure ?

N'ayant pas trouvé de message assez long, pour tester, je me suis dit
que ça ne mangeait pas de pain ;-) . Cela ne touchant que le mise en
forme du message ...


<snip>

lResult = FormatMessage(Format, _
ByVal hMod, _
ErrNo, _
0, _
lpBuffer, &HFFFF&, _
0)



Dans le cas de FORMAT_MESSAGE_ALLOCATE_BUFFER, &HFFFF& serait la
taille du buffer minimum à allouer ; je pense que 0 serait tout à fait
suffisant, mais y a peut-être une raison que j'ai loupée?



J'ai lu Maxi (64K) au lieu de Mini, tout bêtement ...

<private joke>
Peut-être que Jean-Marc t'as trop converti à la philosophie "on en est
pas à quelques Ko de mémoire près" ? :-P
</private joke>



*MESSAGE A JEAN-MARC*

http://www.bellamyjc.org/download/wav/guignols/guy_roux_vos_kilooctets.wav

Ben c'est à dire que nous ne sont pas d'origine auvergnate :-D


If lResult > 0 Then
Buffer = String(lResult, Chr$(0))
CopyMemory ByVal Buffer, ByVal lpBuffer, lResult
End If



Un LocalFree devrait désallouer le lpBuffer après usage...



Yes, là c'est un oubli de ma part, je l'avais vu dans la doc, et je l'ai
zappé ensuite :-(

<snip la fin du code>
A noter que sous Vista, le paramètre dwLanguageID semble superflu, la
localisation se fait automatiquement.



Selon la documentation, les langues sont retrouvées selon:
Language neutral
Thread LANGID, based on the thread's locale value
User default LANGID, based on the user's default locale value
System default LANGID, based on the system default locale value
US English

Ce sera donc exact la plupart du temps, je suppose....



Je n'ai pas pu vérifier. Sous XP Pro FR, le message est en Anglais, je
n'ai pas de version MUI, et je me dis que de toute façon ce n'est pas
très gênant.

Sous Vista Home Premium FR, le message est en français. L'OS est
"Language neutral", mais il y a les .mui dans les sous répertoires fr-FR

Sous Vista Intégrale, le message est affiché dans la langue de la session.

--
Cordialement,

Jacques.
Avatar
François Picalausa
Hello,

<inline>

On Jan 22, 10:55 am, Jacques93 wrote:
François Picalausa a écrit :
> Hello,
> On Jan 20, 2:19 pm, Jacques93 wrote:
>> Bonjour François Picalausa,
>> François Picalausa a écrit :

>>> On Jan 20, 11:29 am, Jacques93 wrote:
>> <snip>

>>> Le top du top serait d'appeler FormatMessage avec
>>> FORMAT_MESSAGE_ALLOCATE_BUFFER pour être certain de ne pas avoir un
>>> buffer trop court. Ca doit pouvoir se faire par CopyMemory...
>> Effectivement le code que j'ai posté est risqué de ce côté là , et peut
>> planter l'application au lieu d'afficher un gentil message, ce qui est
>> tout de même bêta. Je pense que ce code devrait être plus "propre " :

> <snip le début du code>
>>   Format = FORMAT_MESSAGE_FROM_SYSTEM Or _
>>            FORMAT_MESSAGE_ALLOCATE_BUFFER Or _
>>            FORMAT_MESSAGE_MAX_WIDTH_MASK

> Je ne suis pas certain de comprendre pourquoi tu as choisi d'utiliser
> un FORMAT_MESSAGE_MAX_WIDTH_MASK ? Si des linebreaks sont présents à
> l'origine, on peut supposer qu'ils sont utiles, mais j'ai peut-être
> mal compris l'intention?

J'ai surtout du mal a comprendre les nuances de la doc MSDN concernant
l'API FormatMessage:

<Citation>
The low-order byte of dwFlags can specify the maximum width of a
formatted output line. The following are possible values of the
low-order byte
</Citation>

On peut donc se dire que c'est la largeur maxi d'une ligne, non ?
Mais :

<Re-Citation>
If the low-order byte is a nonzero value other than
FORMAT_MESSAGE_MAX_WIDTH_MASK, it specifies the maximum number of
characters in an output line. The function ignores regular line breaks
in the message definition text. The function never splits a string
delimited by white space across a line break. The function stores
hard-coded line breaks in the message definition text into the output
buffer. Hard-coded line breaks are coded with the %n escape sequence.
</Re-Citation>

est un peu (nettement) moins clair pour moi, entre la constante (0xFF)
et d'autres valeurs, 0xFE ou 0x100 par exemple, y a t-il une différence
majeure ?

N'ayant pas trouvé de message assez long, pour tester, je me suis dit
que ça ne mangeait pas de pain ;-) . Cela ne touchant que le mise en
forme du message ...



En fait, selon ce que j'ai compris, il y a 3 cas:
Si les low order bytes sont à 0, on reprend les retours à la ligne
présents dans le message d'origine uniquement.
Cela correspond à
Format = FORMAT_MESSAGE_FROM_SYSTEM Or _
FORMAT_MESSAGE_ALLOCATE_BUFFER

Si les low order bytes sont compris entre 0 et
FORMAT_MESSAGE_MAX_WIDTH_MASK, les retours à la ligne se font tous les
n (= valeur des low order bytes) caractère.
Cela correspond à
Format = FORMAT_MESSAGE_FROM_SYSTEM Or _
FORMAT_MESSAGE_ALLOCATE_BUFFER Or _
3 'Coupe la ligne tous les 3 caractères

Et si on a FORMAT_MESSAGE_MAX_WIDTH_MASK, la fonction ignorerait les
retours à la ligne présents d'origine. Il faudrait tester avec un
fichier de messages correct (après l'avoir mc, rc & link) pour s'en
assurer
Cela correspond à
Format = FORMAT_MESSAGE_FROM_SYSTEM Or _
FORMAT_MESSAGE_ALLOCATE_BUFFER Or _
FORMAT_MESSAGE_MAX_WIDTH_MASK 'ne coupe pas


> <private joke>
> Peut-être que Jean-Marc t'as trop converti à la philosophie "on en e st
> pas à quelques Ko de mémoire près" ? :-P
> </private joke>

*MESSAGE A JEAN-MARC*

http://www.bellamyjc.org/download/wav/guignols/guy_roux_vos_kilooctet...

Ben c'est à dire que nous ne sont pas d'origine auvergnate :-D



<VBG>

>> A noter que sous Vista, le paramètre dwLanguageID semble superflu, la
>> localisation se fait automatiquement.

> Selon la documentation, les langues sont retrouvées selon:
> Language neutral
> Thread LANGID, based on the thread's locale value
> User default LANGID, based on the user's default locale value
> System default LANGID, based on the system default locale value
> US English

> Ce sera donc exact la plupart du temps, je suppose....

Je n'ai pas pu vérifier. Sous XP Pro FR, le message est en Anglais, je
n'ai pas de version MUI, et je me dis que de toute façon ce n'est pas
très gênant.

Sous Vista Home Premium FR, le message est en français. L'OS est
"Language neutral", mais il y a les .mui dans les sous répertoires fr-FR

Sous Vista Intégrale, le message est affiché dans la langue de la sess ion.



Je suppose qu'on peut uniformiser ça par un appel à
GetThreadUILanguage pour retrouver le bon LANGID si nécessaire, et
gérer le possible ERROR_RESOURCE_LANG_NOT_FOUND en faisant un appel
avec 0 par la suite...

François
Avatar
jean-marc
>> <private joke>
Peut-être que Jean-Marc t'as trop converti à la philosophie "on en est
pas à quelques Ko de mémoire près" ? :-P
</private joke>






Hello Jacques,


*MESSAGE A JEAN-MARC*

http://www.bellamyjc.org/download/wav/guignols/guy_roux_vos_kilooctets.wav

Ben c'est à dire que nous ne sont pas d'origine auvergnate :-D




C'est clair !!! On n'a pas peur et on a de la RAM, il faut que ça se sache !

--
JM
Avatar
Jacques93
François Picalausa a écrit :
Hello,



[...]

En fait, selon ce que j'ai compris, il y a 3 cas:
Si les low order bytes sont à 0, on reprend les retours à la ligne
présents dans le message d'origine uniquement.
Cela correspond à
Format = FORMAT_MESSAGE_FROM_SYSTEM Or _
FORMAT_MESSAGE_ALLOCATE_BUFFER

Si les low order bytes sont compris entre 0 et
FORMAT_MESSAGE_MAX_WIDTH_MASK, les retours à la ligne se font tous les
n (= valeur des low order bytes) caractère.
Cela correspond à
Format = FORMAT_MESSAGE_FROM_SYSTEM Or _
FORMAT_MESSAGE_ALLOCATE_BUFFER Or _
3 'Coupe la ligne tous les 3 caractères

Et si on a FORMAT_MESSAGE_MAX_WIDTH_MASK, la fonction ignorerait les
retours à la ligne présents d'origine. Il faudrait tester avec un
fichier de messages correct (après l'avoir mc, rc & link) pour s'en
assurer
Cela correspond à
Format = FORMAT_MESSAGE_FROM_SYSTEM Or _
FORMAT_MESSAGE_ALLOCATE_BUFFER Or _
FORMAT_MESSAGE_MAX_WIDTH_MASK 'ne coupe pas





Merci pour ces précisions.

[...]

Je suppose qu'on peut uniformiser ça par un appel à
GetThreadUILanguage pour retrouver le bon LANGID si nécessaire, et
gérer le possible ERROR_RESOURCE_LANG_NOT_FOUND en faisant un appel
avec 0 par la suite...



Certes, mais le jeu en vaut il la chandelle ? La plupart des dll système
ayant les messages uniquement en anglais. Pour reprendre ton exemple
avec Wininet.dll, si on regarde avec Resource Hacker par exemple :

<http://cjoint.com/?bwn1XmHTmv>

On risque donc d'avoir souvent ERROR_RESOURCE_LANG_NOT_FOUND, ne crois
tu pas ?

Par contre sous Vista, bien que les messages soient similaires à XP dans
Wininet.dll (en-US, 1033), le message est recherché de manière
transparente (sans indiquer de LANGID) dans :

%windir%system32fr-FRWininet.dll.mui

<http://cjoint.com/?bwobpqtwEQ>

si la session est en français, dans :

%windir%system32es-ESWininet.dll.mui

si la session est en espagnol, etc ...

<http://cjoint.com/?bwobpqtwEQ>

--
Cordialement,

Jacques.
1 2