IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

WinDev Discussion :

Création d'une fenêtre popup avec la Flat API


Sujet :

WinDev

  1. #1
    Membre éprouvé
    Profil pro
    Inscrit en
    Novembre 2007
    Messages
    541
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2007
    Messages : 541
    Points : 940
    Points
    940
    Par défaut Création d'une fenêtre popup avec la Flat API
    Voici un exemple montrant la création d'une fenêtre simple de type "Popup", il est basé sur la seule utilisation de la Flat API Windows bas niveau.

    Ce code est identique à celui qui serait utilisé par un programmeur C.
    La seule différence, c'est qu'avec WinDev on est obligé d'utiliser le "code du projet" comme point d'entré, puisque le code n'est pas réellement compilé et que l'on ne peut pas faire abstraction du run-time PC-Soft à savoir :
    1 - L'EXE qui n'est rien d'autre qu'une version modifiée de WD_Test.exe.
    2 - La DLL wd???wm64.dll ou wd???wm32.dll (Machine virtuelle).
    3 - La DLL wd???std64.dll ou wd???std32.dll (Fonctions standard).

    Comme vous pouvez le constater c'est très différent de ce à quoi vous êtes habitué, néanmoins c'est ce type de code qui est à la base de toutes les fenêtres WinDev que vous utilisez (dans l'API bas niveau le mot "fenêtre" = un champ dans le vocabulaire WinDev).

    Ce type de code réellement compilé en code machine produit un EXE de moins de 10 Ko, oui vous avez bien lu, moins de 10000 octets, rien à voir donc avec les monstres actuels, sans parler de la vitesse...

    Ce code "squelette" est écrit une fois pour toute, il suffit de le copier coller dans un nouveau projet pour pouvoir commencer à lui ajouter des muscles, de la peau, des cheveux, des habits, etc. pour produire l'application définitive.

    L'utilisation des API bas niveau permettent de booster les performances d'un projet WinDev, surtout lorsqu'on utilise des DLLs Win32 externes qui sont du véritable code machine.

    La partie la plus intéressante de ce code, est ce qu'on appel le "message cracker" (la fonction callback intitulée "WndProc") et la boucle de message principale qui figure ci-dessous :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    		// Main message pump.		
    		WHILE GetMessage(uMsg, Null, 0, 0)
    			TranslateMessage(uMsg)
    			DispatchMessage(uMsg)
    		END
    qui est le centre névralgique du traitement de tous les messages que Windows envoi à votre application. (le cœur du multitâche).

    Une autre chose à mon avis très importante lorsqu'on programmes l'API bas niveau avec WinDev, c'est de toujours afficher le code en anglais pour faciliter le copier coller d'un langage à l'autre. Car n'oubliez pas, l'API bas niveau, est le seul dénominateur commun de tous les langages de programmation Windows.

    Le fichier Mini.zip (attaché à ce post), contient le code qui peut être "compilé" soit en mode 32-bit, soit en mode 64.
    Fichiers attachés Fichiers attachés

  2. #2
    Membre émérite
    Avatar de DelphiManiac
    Homme Profil pro
    Homme à tout faire
    Inscrit en
    Mars 2002
    Messages
    1 147
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Homme à tout faire
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2002
    Messages : 1 147
    Points : 2 533
    Points
    2 533
    Par défaut
    (le cœur du multitâche).
    Juste pour information, depuis la technologie dites NT (ie Windows NT 3.1 pour la branche server et Windows 2000 pour la branche workstation), le multitâche ne repose plus sur la boucle de message. Il est dis "préemptif", le système peut interrompre une tâche que celle ci l'autorise ou pas alors qu'auparavant il étais dis "coopératif", chaque tâche pouvait bloquer la totalité du système.

    [Edit]Sinon bel exemple de l'implémentation bas niveau du code minimal pour afficher une fenêtre. Par contre, je ne comprend pas trop ce que cela peut apporter au développeur Windev, sauf si cet exemple n'est là qu'au titre de démonstration "académique" de l'utilisation de l'API Win32, dans ce cas, il a toute son utilité.

  3. #3
    Membre éprouvé
    Profil pro
    Inscrit en
    Novembre 2007
    Messages
    541
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2007
    Messages : 541
    Points : 940
    Points
    940
    Par défaut
    je ne comprend pas trop ce que cela peut apporter au développeur Windev
    La question de l'utilisation des API bas niveau a été le sujet de plusieurs messages récemment.

    C'est donc bien un exemple académique, destiné à montrer ce qui est à la base de tout programme utilisant l'API pour créer la fenêtre mère d'une application, car il faut bien commencer par le B A, BA.

    A titre de comparaison, voici exactement le même code en PowerBASIC.
    Vous constaterez aisément la similitude de syntaxe avec le code WinDev (écrit en anglais).

    La différence majeure est que l'un peut être compilé en code machine natif, il produit alors un EXE de seulement 8704 octets, sans aucun runtime ni Framework (voir le ZIP attaché à ce post).

    Code source PowerBASIC
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95
    96
    97
    98
    99
    100
    101
    102
    103
    104
    105
    106
    107
    108
    109
    110
    111
    112
    113
    114
    115
    116
    117
    118
    119
    120
    121
     
    #COMPILE EXE "MiniPB.exe"
     
    #INCLUDE "MiniPB.inc" '// Flat API declaration
     
    %ClientW            = 640
    %ClientH            = 480
     
    TYPE PROP
        hMain           AS DWORD
        MinTrackSizeW   AS LONG
        MinTrackSizeH   AS LONG
    END TYPE
     
    GLOBAL gP AS PROP ''// Global class properties
     
    FUNCTION WndProc(BYVAL hWnd AS DWORD, BYVAL Msg AS DWORD, BYVAL wParam AS DWORD, BYVAL lParam AS DWORD) AS LONG
        LOCAL ps AS PAINTSTRUCT
        LOCAL rc AS RECT
     
        SELECT CASE LONG Msg
     
        CASE %WM_GETMINMAXINFO
             LOCAL pMM AS MINMAXINFO PTR
             pMM = lParam
             @pMM.ptMinTrackSize.x = gP.MinTrackSizeW
             @pMM.ptMinTrackSize.y = gP.MinTrackSizeH
     
        CASE %WM_SIZE
             InvalidateRect(hWnd, BYVAL(%NULL), %TRUE)
     
        CASE %WM_COMMAND
             LOCAL wmId, wmEvent AS LONG
             wmID    = LOINT(wParam)
             wmEvent = HIINT(wParam)
             '//SELECT CASE LONG LOWRD(wParam)
             '//
             '//END SELECT
     
        CASE %WM_PAINT
             LOCAL hDC AS DWORD
             hDC = BeginPaint(hWnd, ps)
             '// Paint the window content here
             EndPaint(hWnd, ps)
             FUNCTION = 0: EXIT FUNCTION
     
        CASE %WM_DESTROY
             PostQuitMessage(0)
             FUNCTION = 0: EXIT FUNCTION
     
        END SELECT
     
        FUNCTION = DefWindowProc(hWnd, Msg, wParam, lParam)
     
    END FUNCTION
     
    FUNCTION WinMain (BYVAL hInstance     AS LONG, _
                      BYVAL hPrevInstance AS LONG, _
                      BYVAL lpCmdLine     AS ASCIIZ PTR, _
                      BYVAL iCmdShow      AS LONG) AS LONG
     
        LOCAL nRet     AS DWORD
        LOCAL wcx      AS WNDCLASSEXA
        LOCAL szClass  AS ASCIIZ * 16
        szClass = "FLAT_API_POPUP" '// The class name of our popup window.
     
        wcx.cbSize = SIZEOF(wcx)
        LOCAL IsInitialized AS LONG
        IsInitialized = GetClassInfoEx(hInstance, szClass, wcx)
        IF IsInitialized&   = 0 THEN
            wcx.style         = %CS_HREDRAW OR %CS_VREDRAW
            wcx.lpfnWndProc   = CODEPTR(WndProc)
            wcx.cbClsExtra    = 0
            wcx.cbWndExtra    = 0 '// %EXTEND_EXTRA * 4
            wcx.hInstance     = hInstance
            wcx.hIcon         = %NULL
            wcx.hCursor       = LoadCursor(%NULL, BYVAL %IDC_ARROW)
            wcx.hbrBackground = GetStockObject(%WHITE_BRUSH)
            wcx.lpszMenuName  = %NULL
            wcx.lpszClassName = VARPTR(szClass)
            wcx.hIconSm       = wcx.hIcon
            IF RegisterClassEx(wcx) THEN IsInitialized = %TRUE
        END IF
     
        IF IsInitialized THEN
            LOCAL r AS RECT
            LOCAL uMsg AS TagMSG
            LOCAL dwExStyle, dwStyle, hMain AS DWORD
            LOCAL x, y AS LONG
     
            dwExStyle = %WS_EX_APPWINDOW OR %WS_EX_WINDOWEDGE
            dwStyle = %WS_POPUP OR %WS_CAPTION OR %WS_SYSMENU OR %WS_THICKFRAME OR %WS_MINIMIZEBOX OR %WS_MAXIMIZEBOX OR %WS_CLIPSIBLINGS OR %WS_CLIPCHILDREN
     
            SetRect(r, 0, 0, %ClientW, %ClientH)
            AdjustWindowRectEx(r, dwStyle, %FALSE, dwExStyle)
     
            gP.MinTrackSizeW = r.nRight - r.nLeft
            gP.MinTrackSizeH = r.nBottom - r.nTop
            x = MAX&((GetSystemMetrics(%SM_CXSCREEN) - gP.MinTrackSizeW) \ 2, 0)
            y = MAX&((GetSystemMetrics(%SM_CYSCREEN) - gP.MinTrackSizeH) \ 2, 0)
     
            gP.hMain = CreateWindowEx(dwExStyle, szClass, "Popup window 32-bit", dwStyle, _
                                      x, y, gP.MinTrackSizeW, gP.MinTrackSizeH, 0, 0, hInstance, BYVAL %NULL)
     
            IF gP.hMain THEN
     
                ShowWindow(gP.hMain, iCmdShow)
                SetForegroundWindow(gP.hMain) '// Slightly Higher Priority
     
                WHILE GetMessage(uMsg, %NULL, 0, 0)
                     TranslateMessage(uMsg)
                     DispatchMessage(uMsg)
                WEND
     
                nRet = uMsg.wParam
            END IF
     
        END IF
     
        FUNCTION = nRet
    END FUNCTION
    Le principal intérêt de l'utilisation de PowerBASIC avec WinDev, est qu'il permet de compiler de véritables DLL Win32 natives, ce que ni le code IL (DotNET) ni le p-code de WinDev ne peuvent faire.

    ...
    Fichiers attachés Fichiers attachés

  4. #4
    Membre émérite
    Homme Profil pro
    Inscrit en
    Octobre 2007
    Messages
    1 075
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations forums :
    Inscription : Octobre 2007
    Messages : 1 075
    Points : 2 451
    Points
    2 451
    Par défaut
    Bonjour

    Comparer le code PowerBasic au code de bas niveau n'apporte pas de réponse à l'objection d'Hibernatus, que je partage.
    je ne comprend pas trop ce que cela peut apporter au développeur Windev
    Mon premier micro, fin des années 70, était un Dynalogic XXX (fabriqué au Canada) basé sur un Motorola 6800, 16 Ko de RAM, 2 floppies grand format "Hard formattés" de 256 Ko chacun !
    Avec cela, soit on travaillait en assembleur, soit on disposait d'un basic "tout nu" avec 26 variables texte et 26 variables de type entier ou numérique (j'ai oublié), A à Z chacune.
    Dont coût : +/- 13.000 euros à l'époque (ce qui laisse rêveur : si on veut faire une projection en tenant compte de l'inflation, que ne pourrait-on pas s'offrir avec un tel budget)
    On swappait constamment le contenu de nos variables sur les disquettes pour pouvoir les réallouer, on changeait les disquettes et on compactait les données au maximum, exploitant le moindre bit (pas byte ou octet, mais bit).
    Etape suivante : véritable miracle, alléluia, le basic s'est enrichi d'un ISAM et les variables sont passées à 2 lettres (AA à ZZ) et les disquettes sont passées à 512 Ko; du coup on s'est payé 16 Ko supplémentaire de RAM et on est passé à 32 Ko

    Maintenant, si on considère les systèmes d'entrée de gamme, on parle en gigaoctets de RAM, en centaine de gigaoctets de stockage disque et de processeurs fabuleux.

    Donc, sauf besoins très spécifiques, si on fait de la gestion, on ne "s'embête" ni ne "s'amuse" pas avec les instructions de bas niveau et on n'a pas besoin de "compiler de véritables DLL Win32 natives"
    Et si on développe sous Windev, c'est a priori pour des applications de gestion.
    Il faut aussi se poser la question de savoir, si tout en développant des applications conviviales et enrichies, nous devons offrir une interface digne d'un jeu haut de gamme.
    Pour moi, la réponse est évidemment négative. Tout ce qui peut faciliter la vie de l'utilisateur est le bienvenu, tout ce qui le distrait ou surcharge l'écran ou les manipulations doit être évité.

    D'accord, C me démange et je me dis qu'un jour je m'y remettrai pour le plaisir et c'est vrai que j'aimerais reprendre un peu d'assembleur.
    Mais ce ne sont pas les outils adéquats pour des applications de gestion et, en sus, si on ne les pratique pas/plus régulièrement, on va certainement s'y paumer.

    Je suis également convaincu que dans beaucoup de cas, une bonne optimisation du code et de l'organisation des données amènerait pas mal d'applications poussives à un niveau de performances plus qu'honorable.

    Il faut également objectiver la notion de "poussivité" d'une application : il y a une différence entre une lenteur chronométrée et l'impatience des utilisateurs.
    Une de mes connaissances, responsable informatique dans une banque à l'époque de l'IBM 34, avait - à la satisfaction générale - résolu le problème de la manière suivante : au lieu d'attendre la fin d'un traitement pour en afficher le résultat à une vitesse de 9.600 bauds, il commençait - dès l'envoi de la touche Enter - à afficher le masque de l'écran de réponse, puis les éléments de résultats, mais à une vitesse de 1.200 bauds.
    Tout le monde avait salué l'amélioration spectaculaire de la réactivité du système ...

  5. #5
    Membre éprouvé
    Profil pro
    Inscrit en
    Novembre 2007
    Messages
    541
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2007
    Messages : 541
    Points : 940
    Points
    940
    Par défaut
    Monsieur HEMGE

    J'ai consacré un peu de temps pour écrire ces exemples sur l'API bas niveau à l'attention de ceux qui ont manifesté récemment un intérêt sur ce sujet.

    Je précise également que WinDev n'est pas utilisé uniquement dans le cadre limité des applications de gestion, pour lequel les impératifs de vitesse de traitement n'ont pas beaucoup d'importance.

    J'ai l'intention de poster un OVNI d'envergure (qui fait du traitement temps réel), mais il est bien éloigné des applications de gestion auxquelles vous faites allusion, pourtant j'ai quand même choisi WinDev pour l'écrire, principalement en raison des facilités offertes par l'éditeur de champs (héritier de HighScreen) qui me permet de modifier facilement l'interface utilisateur (et gagner beaucoup de temps).

    ...

  6. #6
    Membre éprouvé
    Profil pro
    Inscrit en
    Novembre 2007
    Messages
    541
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2007
    Messages : 541
    Points : 940
    Points
    940
    Par défaut
    Monsieur Hemgé

    Merci de relire mon message que j'ai modifié en même temps que vous postiez votre réponse.

  7. #7
    Membre émérite
    Homme Profil pro
    Inscrit en
    Octobre 2007
    Messages
    1 075
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations forums :
    Inscription : Octobre 2007
    Messages : 1 075
    Points : 2 451
    Points
    2 451
    Par défaut
    Citation Envoyé par Patrice Terrier Voir le message
    Monsieur Hemgé

    Merci de relire mon message que j'ai modifié en même temps que vous postiez votre réponse.
    Merci Monsieur Terrier

    Le Forum ne peut que mieux se porter de cette évolution.
    Du coup, j'ai supprimé ma réaction qui n'a plus lieu d'être.

    Bon week-end

    Hemgé

  8. #8
    Membre expérimenté
    Inscrit en
    Août 2010
    Messages
    730
    Détails du profil
    Informations forums :
    Inscription : Août 2010
    Messages : 730
    Points : 1 648
    Points
    1 648
    Par défaut
    Citation Envoyé par Hemgé Voir le message
    Comparer le code PowerBasic au code de bas niveau n'apporte pas de réponse à l'objection d'Hibernatus, que je partage.
    Merci d'abonder dans mon sens, mais je n'ai encore rien dit.

  9. #9
    Membre averti
    Profil pro
    au repos
    Inscrit en
    Février 2013
    Messages
    156
    Détails du profil
    Informations personnelles :
    Localisation : Saint-Pierre-Et-Miq.

    Informations professionnelles :
    Activité : au repos

    Informations forums :
    Inscription : Février 2013
    Messages : 156
    Points : 331
    Points
    331
    Par défaut
    Fais attention Hemgé, tu va réveiller Hibernatus

Discussions similaires

  1. Réponses: 3
    Dernier message: 17/02/2011, 16h39
  2. création une fenêtre MDI avec java
    Par infoelectronique dans le forum AWT/Swing
    Réponses: 2
    Dernier message: 21/01/2009, 17h01
  3. Réponses: 0
    Dernier message: 04/09/2008, 19h43
  4. Response.Redirect avec Création d'une fentre
    Par jerome.fortias dans le forum ASP.NET
    Réponses: 3
    Dernier message: 13/09/2007, 18h05
  5. [Javascript] Problème avec une fenêtre popup.
    Par mika0102 dans le forum Général JavaScript
    Réponses: 4
    Dernier message: 18/05/2005, 10h50

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo