Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Matériel Ordinateur Système PC GlobalLock/Unlock

GlobalLock/Unlock

7 réponses
Avatar
Alni
Bonjour,

Après quelques recherches sur le net, j'ai réussi à implémenter une
fonction qui permet de forcer le mode LANDSCAPE ou PORTRAIT en me
basant sur les exemples. Mais j'ai un doute sur les Globallock et
Unlock.

Dans certains exemples je vois un GlobalLock avant de modifier le
DEVMODE puis un GlobalUnlock juste après.
Dans d'autres exemples, je vois juste un GlobalUnlock juste avant cette
modif.

J'ai implémenté de la façon ci dessous, et cela fonctionne. Mais
comment dois-je proeder exactement pour rester "clean" avec le système
?

m_Landscape est une variable bool, membre de la classe qui contient
TRUE/FALSE selon le choix.
*pd contient le pointer sur la boite de dialogue d'impression
---------------------------8<----------------------
void CMyPrint::SetLandscape(CPrintDialog *pd)
{
if (AfxGetApp()->GetPrinterDeviceDefaults(&pd->m_pd))
{
LPDEVMODE dev = pd->GetDevMode();
GlobalUnlock(dev);
dev->dmOrientation= m_Landscape ? DMORIENT_LANDSCAPE :
DMORIENT_PORTRAIT;
dev->dmFields |= DM_ORIENTATION;
}

}

--
Alni
Signaler un problème avec ce contenu

7 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
Avatar
Patrick 'Zener' Brunet
Bonjour.

C'est de la programmation Windows [hyper-archaïque] tout ça !

"Alni" a écrit dans le message de news:

Dans certains exemples je vois un GlobalLock avant de modifier le
DEVMODE puis un GlobalUnlock juste après.
Dans d'autres exemples, je vois juste un GlobalUnlock juste avant cette
modif.



In antiquis temporibus (16bitis), Windows se réservait la possibilité de
déplacer ses petits bouts de mémoire pour faire de la place, et donc ils
étaient désignés par un HANDLE, et devaient être verrouillés pour disposer
d'un pointeur stable, puis déverrouillés.

A moins que vous n'utilisiez encore un Windows 3.1, il y a longtemps que la
mémoire ne se ballade plus, donc GlobalLock() et GlobalUnlock() ne font plus
rien.
Ou plutôt, GlobalLock() convertit le HANDLE en un LPMACHIN, mais ce dernier
reste valide jusqu'à destruction de l'objet associé.

Ceci subsiste parce que les exemples de code datent de cette époque... Bref,
je crois que vous pouvez virer les GlobalUnlock() sans souci, et après
création de l'objet, faire un GlobalLock() dans la foulée sur le HANDLE pour
avoir le pointeur.

D'ailleurs vous pouvez ne garder que le pointeur et jeter le HANDLE, vous le
retrouverez avec GlobalHandle() quand vous en avez besoin (pour détruire
l'objet notamment).

Cordialement,

--

/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/

Avatar
Alni
Bonjour,

Patrick 'Zener' Brunet a présenté l'énoncé suivant :
Bonjour.

C'est de la programmation Windows [hyper-archaïque] tout ça !


Erreur de forum, j'ai envoyé un cancel juste après, mais visiblement il
est passé quand même.

Pourquoi archaïque, c'est du VC++ 6.0 SP6 avec les MFC. Je ne suis pas
trop tenté de passer au C#, il m'a fallu déja quelques temps pour
passer du C au C++ FraweWork MFC il y a quelques années.
Et qu'on ne me parle pas de VB ou autres trucs du genre, je n'ai jamais
compris pourquoi c'était aussi compliqué à faire des trucs qui sont si
simples en C.

Quoi que ça fait un moment que je n'y ai pas regardé de près, c'est
peut être devenu plus facile de faire tout ce que je trouvais compliqué
en VB et si simple en C.
M'enfin, il restera toujours qu'il faut se charger la msVBx.DLL de
1,4Mo....
Et de toutes façons j'ai arrété le basic depuis plus de 17ans, alors
pas trop envie de m'y remettre.

--
Alni

Avatar
Patrick 'Zener' Brunet
Bonsoir.

(vous me direz où est la suite, j'ai pas trouvé)

"Alni" a écrit dans le message de news:

Patrick 'Zener' Brunet a présenté l'énoncé suivant :

C'est de la programmation Windows [hyper-archaïque] tout ça !


Pourquoi archaïque, c'est du VC++ 6.0 SP6 avec les MFC. Je ne suis pas
trop tenté de passer au C#, il m'a fallu déja quelques temps pour
passer du C au C++ FraweWork MFC il y a quelques années.
Et qu'on ne me parle pas de VB ou autres trucs du genre, je n'ai jamais
compris pourquoi c'était aussi compliqué à faire des trucs qui sont si
simples en C.



Perso je n'aime pas les frameworks, je préfère les programmes autonomes. Un
jour j'ai téléchargé une petite démo : un EXE de 9Ko, et pour l'exécuter il
m'a fallu télécharger le framework .NET et l'installer (respectivement 24Mo
et 150 sur disque, soit 273000 et 1707000 fois sa taille. Sans
commentaire...). Tout ça c'était un choix de l'auteur pour avoir une petite
fenêtre violette avec un champ dedans !

Les MFC apportent la prise en charge standard d'énormément de choses dans la
structure fenêtrée d'une application, surtout en utilisant le Wizard pour
mettre en rapport automatiquement les ressources et la plupart des éléments
d'interface (menus, icônes, texte dans la barre d'état, raccourcis, etc.).
Par contre si vous voulez faire un truc pas prévu, là ça devient vraiment
galère ! C'est un choix stratégique en début de projet...

Et donc je confirme que même dans le VC6 il y a tout un héritage qui date
des débuts de Windows (comme ces histoires de pointeurs longs et courts et
de "locks" sur les segments). Suffit de le savoir...

Quoi que ça fait un moment que je n'y ai pas regardé de près, c'est
peut être devenu plus facile de faire tout ce que je trouvais compliqué
en VB et si simple en C.
M'enfin, il restera toujours qu'il faut se charger la msVBx.DLL de
1,4Mo....
Et de toutes façons j'ai arrété le basic depuis plus de 17ans, alors
pas trop envie de m'y remettre.



Il semble bien clair que l'Editeur a abandonné le support de VB au profit de
C# et de l'architecture .NET.

De toute manière, il n'y a pas de langage magique, c'est le développeur qui
est bon ou pas, et s'il est bon il voudra un langage qui ne le bride pas.
Donc si vous en maîtrisez un, gardez-le. Surtout si c'est C ou C++ qui
resteront longtemps encore bons à tout faire ET universellement portables.

Cordialement,

--

/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/


Avatar
Alni
Bonjour,

Patrick 'Zener' Brunet a formulé ce mercredi :

Perso je n'aime pas les frameworks, je préfère les programmes autonomes. Un
jour j'ai téléchargé une petite démo : un EXE de 9Ko, et pour l'exécuter il
m'a fallu télécharger le framework .NET et l'installer (respectivement 24Mo
et 150 sur disque, soit 273000 et 1707000 fois sa taille.


Oui, mais avec les MFC c'est plus simple : La MFC42.dll est dispo sur
toutes les machines 2000 et XP et de toutes façons, on peut linker les
parties de MFC utilsé dans le .exe sans trop le faire grossir si on
pense qu'il sera utilisé sous 98.
En général, cela fait passer par exemple un exe de 60ko à 200Ko.
Et avec 60Ko, je fais un programme d'impression de billet pour une
salle de spectacle, avec choix de la taille des polices, des places
numérotés selon le plan de salle, un aperçu avant impression du billet
et toutes les mentions légales sur la souche et le coupon de contrôle.

Par contre si vous voulez faire un truc pas prévu, là ça devient vraiment
galère !


Si c'est pas prévu, on dérive un classe de l'objet qui s'approche le
plus de ce que l'on veut faire.

Et donc je confirme que même dans le VC6 il y a tout un héritage qui date
des débuts de Windows (comme ces histoires de pointeurs longs et courts


En fait je pense que le type FAR n'est encore dans les compilos que
pour assurer la portabilité des sources, ou pour faire du code 16bit.
Il est clair que maintenant c'est en 32bits et il faudrait que je
regarde le #define du FAR dans les MFC pour voir.

--
Alni

Avatar
tmartin
En fait je pense que le type FAR n'est encore dans les compilos que
pour assurer la portabilité des sources, ou pour faire du code 16bit.
Il est clair que maintenant c'est en 32bits et il faudrait que je
regarde le #define du FAR dans les MFC pour voir.


Je n'ai plus les headers pour vérifier, mais dans la documentation
papier que j'utilisais, il précisait que cette directive n'avait plus
d'effets.

Avatar
Alni
Bonjour,


Il est clair que maintenant c'est en 32bits et il faudrait que je
regarde le #define du FAR dans les MFC pour voir.


Je n'ai plus les headers pour vérifier, mais dans la documentation
papier que j'utilisais, il précisait que cette directive n'avait plus
d'effets.


Merci, c'est bien ce que je pensais :)

--
Alni


Avatar
Alni
Bonjour,

Patrick 'Zener' Brunet a pensé très fort :
Bonsoir.

(vous me direz où est la suite, j'ai pas trouvé)


J'ai eu cette réponse sur microsoft.public.vc.mfc
------------------------8<-----------------
If anything, the code ought to be:

LPDEVMODE dev = pd->GetDevMode();
dev->dmOrientation= m_Landscape ? DMORIENT_LANDSCAPE :
DMORIENT_PORTRAIT;
dev->dmFields |= DM_ORIENTATION;
GlobalUnlock(dev);

--
Alni