Announcement

Collapse
No announcement yet.

Identified Technical Issues

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Identified Technical Issues

    I'll go first:

    While working with the DDT version of Fred's example I ended up with what Elias called "verbose" code. I've posted my reasoning in that thread. Here's the technical issue I think I was dealing with:

    Windows sends multiple focus messages through the CALLBACK. Most are not related to any user action. Without resorting to SDK, is there another way to make sure we respond only to the user initiated focus message?

    I use HasFocusFlag to track which control currently has focus.
    I use the MessageBoxCount to respond only to the first focus message sent by cmdButton2.

    Code:
    CALLBACK FUNCTION ShowfrmVBConvertProc()
       STATIC HasFocusFlag AS LONG         'track control with focus
       STATIC MessageBoxCount AS LONG      'track number of calls to MSGBOX
    
       IF HasFocusFlag = %IDC_cmdButton2 THEN    'tracking only MSGBOX calls for button2
          INCR MessageBoxCount
       ELSE
          MessageBoxCount = 0
       END IF
    
    
       SELECT CASE AS LONG CBMSG
          CASE %WM_INITDIALOG
             ' Initialization handler
    
          CASE %WM_NCACTIVATE
             STATIC hWndSaveFocus AS DWORD
             IF ISFALSE CBWPARAM THEN
                ' Save control focus
                hWndSaveFocus = GetFocus()
             ELSEIF hWndSaveFocus THEN
                ' Restore control focus
                SetFocus(hWndSaveFocus)
                hWndSaveFocus = 0
             END IF
    
          CASE %WM_COMMAND
             ' Process control notifications
             SELECT CASE AS LONG CBCTL
    
                'test for %BN_SETFOCUS message to control the MSGBOX for button2 focus
                CASE %IDC_cmdButton1
                   SELECT CASE AS LONG CBCTLMSG
                      CASE %BN_CLICKED
                         CONTROL SET TEXT CBHNDL, %IDC_txtText1, "You Clicked cmdButton1 (the top button)!"
                      CASE %BN_SETFOCUS
                         HasFocusFlag = %IDC_cmdButton1
                   END SELECT
    
                CASE %IDC_cmdButton2
                   SELECT CASE AS LONG CBCTLMSG
                      CASE %BN_CLICKED
                         CONTROL SET TEXT CBHNDL, %IDC_txtText1, "You Clicked cmdButton2 (the middle button)!"
    
                      CASE %BN_SETFOCUS
                         HasFocusFlag = %IDC_cmdButton2
                         INCR MessageBoxCount
                         IF MessageBoxCount = 1 THEN
                            MSGBOX "Button #2 just got a GotFocus message."
                            CONTROL SET FOCUS CBHNDL, %IDC_cmdButton2
                         ELSE
                            CONTROL SET TEXT CBHNDL, %IDC_txtText1, "You Clicked cmdButton2 (the middle button)!"
                         END IF
                   END SELECT
    
                CASE %IDC_cmdButton3
                   SELECT CASE AS LONG CBCTLMSG
                      CASE %BN_CLICKED
                         CONTROL SET TEXT CBHNDL, %IDC_txtText1, "You Clicked cmdButton3 (the bottom button)!"
                      CASE %BN_SETFOCUS
                         HasFocusFlag = %IDC_cmdButton3
                   END SELECT
    
                CASE %IDC_txtText1
    
             END SELECT
    
       END SELECT
    END FUNCTION
    Do not go quiet into that good night,
    ... Rage, rage against the dark.

  • #2
    Multiple Instances and Class Registration

    Is this something we should be aware of?

    User to user discussions about the PB/Win (formerly PB/DLL) product line. Discussion topics include PowerBASIC Forms, PowerGEN and PowerTree for Windows.
    Do not go quiet into that good night,
    ... Rage, rage against the dark.

    Comment


    • #3
      Im sorry stan, maybe i went too far ahead. You was only trying to prove
      it can be done, but since i already knew it, i went ahead trying to give
      advice how to improve (and make faster, which is my specialty) the code.

      About the Focus message, have you tried WM_KILLFOCUS and WM_SETFOCUS ?

      Activating the non client area is a side effect of receiving focus, and AFAIK
      WM_SETFOCUS and WM_KILLFOCUS include more information.

      Comment


      • #4
        Originally posted by Elias Montoya View Post
        Im sorry stan, maybe i went too far ahead. You was only trying to prove
        it can be done, but since i already knew it, i went ahead trying to give
        advice how to improve (and make faster, which is my specialty) the code.

        About the Focus message, have you tried WM_KILLFOCUS and WM_SETFOCUS ?

        Activating the non client area is a side effect of receiving focus, and AFAIK
        WM_SETFOCUS and WM_KILLFOCUS include more information.

        No apologies necessary. I have a very thick skin when I'm working on a team project.

        Yes, I did try the WM_ focus messages. That's when I discovered that the OS was sending many times the number of WM_KILLFOCUS actually needed by the sample app. According to MSDN the KillFocus message returns the control receiving focus and I just couldn't figure out another way to account for that in my sample.

        I was sincere when I asked you to show me. I really do want to see if there's a better way.

        Stan
        Do not go quiet into that good night,
        ... Rage, rage against the dark.

        Comment


        • #5
          Maybe there is.

          When you receive the EM_SETFOCUS, it includes the previous window that had the focus, check that value, if Previous focused window <> Currently focused window then fire up the message box that displays the focus change, otherwise just ignore it.

          Comment


          • #6
            The EM_SETFOCUS is not defined in my version of the Win32api.inc or the DDT.inc. GREPed my api directory -- 37 definitions that include "SETFOCUS", but no "EM_SETFOCUS".

            That's why I didn't try it: Couldn't find it.

            Can you test for that message without using an SDK call?
            Do not go quiet into that good night,
            ... Rage, rage against the dark.

            Comment


            • #7
              That was a typo.. sorry about that. I meant WM_SETFOCUS.

              Comment


              • #8
                This from John Heathcoate. Something to consider when we get to the point of addressing end-user options in the first release.

                As for the direction of the converter project I'm in favor of keeping some of the VB control event syntax, possibly as a user defined option. All I want is to know where to put a control "LostFocus" event, or the PB equivalent in my PB code. One frustrating thing about PB is that if I'm in a prototype mode I don't want to think about how to respond to a "LostFocus" event in PB, I want to put the required code to do something in that event no fuss no muss. I can tell you I have literally wasted weeks upon weeks of time relearning how to emulate a VB capability in PB. I think my time could be better spent concentrating on my prototyping rather than researching language differences between VB and PB. IMHO most VB'ers would feel the same way.
                Do not go quiet into that good night,
                ... Rage, rage against the dark.

                Comment


                • #9
                  I recognize that VBers are going to want to try and have things the way they had them, and to some extent, we should try to fill that need.

                  The fact of the matter is though, that VB is no longer the VB that they knew and used.

                  This converter should, IMO, try to lessen the struggle of those moving from a dead language to a vibrant one.

                  Wanting the same as before from us is like trying to create VB for them and that is analogous to trying to make Windows work like DOS for those that loved DOS.

                  There may be features that we can somehow imitate, and perhaps should, but I think that getting the VBers accustomed to PB ways should be in the forefront, especially in the first version or two.

                  If we are to use this to create VB features then we are creating a PB to VB converter, not the other way around.

                  Rod
                  Rod
                  In some future era, dark matter and dark energy will only be found in Astronomy's Dark Ages.

                  Comment


                  • #10
                    Originally posted by Rodney Hicks View Post
                    I recognize that VBers are going to want to try and have things the way they had them, and to some extent, we should try to fill that need.

                    The fact of the matter is though, that VB is no longer the VB that they knew and used.

                    This converter should, IMO, try to lessen the struggle of those moving from a dead language to a vibrant one.

                    Wanting the same as before from us is like trying to create VB for them and that is analogous to trying to make Windows work like DOS for those that loved DOS.

                    There may be features that we can somehow imitate, and perhaps should, but I think that getting the VBers accustomed to PB ways should be in the forefront, especially in the first version or two.

                    If we are to use this to create VB features then we are creating a PB to VB converter, not the other way around.

                    Rod
                    My second thought (after I posted this and thought about how PB handles event messages) was to provide the end-user with a list that tells him where to find the PB code that handles his VB events.

                    More in keeping with what we're trying to do here.

                    thinking out loud,
                    Stan
                    Do not go quiet into that good night,
                    ... Rage, rage against the dark.

                    Comment


                    • #11
                      Tech Issue: lexer functionality

                      Topic: Lexer Functionality.
                      1. The unit of lexing in the VB procedural source code will be the statement, not line of code. I assume that multistatement lines and multiline statements can exist in VB? So there's a task: read the source code and send statements to the lexer. I have no idea how this will work with forms.

                      2. Looking at updating the DD, I've got to the point where it comes upon an atom (=lexeme, I don't like this l-word) which is not in the DD. Now we're in trouble. The lexer needs to put all sorts of information into the DD, but all it has is the atom text and placement details. This can happen either in a declaration or in an implicit declaration or in non-working code. The lexer wants to call a function with all the relevant info, and have that function return a pointer to a UDT (at a guess) which the lexer can use to populate the DD with. I don't have that function, it is the philosopher's stone of this project!

                      Also, the function is going to be different depending upon whether we are dealing with a form or with procedural code. Two functions.

                      So the function receives a pointer to the lexed statement - or should that be expression? Another job to do, write a function to extract expressions from the lexed statement. Does that give it sufficient context to tokenize the atom?

                      Background: Looking at what I think will be needed in the DD (at least a start):

                      DDMaster table has all the builtin info, DD<application> tables start life as copies of it.

                      Code:
                      TABLE DDmaster, etc
                      column            description
                      -----------------------------------------------------------------------------------
                      context           "builtin",".FRM","GLOBAL","DLG","LOCAL" etc
                      type              the token's type, eg "operator","builtin function","user function",
                                        a seperate rules table required to control this 
                      classname         the classname or variable subtype, etc. Another rules table?
                      VBtoken           the token string
                      nargs             the number of arguments apparently supplied
                      declared          2 if this entry results from an explicit declaration
                                        1 if from first reference without a declaration
                                        0 if builtin
                                        ' following 3 refer to the declaration/first use
                      SFno              the source file reference no, looks up SourceFiles table
                      SFLine            source file line
                      SFstmnt           source file statement
                      refcount          count of references to this token (debugging really)
                      PBtoken           the equivalent PB token if the translation is 1:1
                      PBTransproc       the address of a translation procedure - for use by the PB writers
                      In summary of technical issues raised
                      1. A function is required to turn an atom/lexeme into a token, attributes of which will populate the DD. May be best to return the token attributes in a UDT so the lexer can populate the DD. I imagine that this function will receive a ptr to a UDT containing the context of an expression, being source file (via source files table), line no, statement-in-line-no, and the lexed expression, which will probably need to go in an array.

                      3. Not 100% a technical issue, but one that needs looking at. Lexing of FRMs is unknown (to me) territory. It will require different treatment.
                      Last edited by Chris Holbrook; 21 Jun 2008, 02:05 PM. Reason: add description of context column

                      Comment


                      • #12
                        Stan,

                        My second thought (after I posted this and thought about how PB handles event messages) was to provide the end-user with a list that tells him where to find the PB code that handles his VB events.

                        More in keeping with what we're trying to do here.
                        I could go along with that, personally Windoze messages confuse the (you know what) out of me because they do not appear to operate consistently, if some flag is set the message must be handled under %WM_NOTIFY rather than %WM_COMMAND. It appears there are more exceptions to the rule.

                        If we could put together some POFFS like informational repository at the users finger tips that would show where the VB event needs to be coded in PB, it would make me a happy camper. With this information available it would be up to the user to actually insert it in the code, let the user decide if they want to put VB in their PB code, but I agree that this functionality should not be an intrinsic part of the converter.

                        I hope I didn't give the wrong impression that I wanted PB to operate like VB, far from it. But when you are attempting to translate several thousand lines of VB code into the PB equivalent, the last thing I want to do is figure out is how to do something simple, or restructure my PB code to handle something like updating my INI file from the text box LostFocus event for the first translation. All I want my PB code to do at this point is to work and provide roughly the same functionality (and results) as my VB program. Once I'm satisfied with my translation I then go about cleaning it up for PB.
                        Later...

                        JR

                        "When governments fear the people there is liberty. When people fear the government there is tyranny." - Thomas Jefferson

                        Comment


                        • #13
                          Regarding standards to work to:

                          here's my latest version of equates and types for the Tokenizer. I think most of these will be self explanatory. Concept I'm using is that there will be a file containing a LOT of built-in types as part of the overall Reference Dictionary package and the Converter will build arrays containing only those that are actually referenced in the VB code being processed. This should allow doing most of the work in RAM (minimize HD access -- it's an idea Fred & Chris were working on).

                          Code:
                          'PBWin variable types & term descriptors
                          %pbByte                 = 501
                          %pbInteger              = 502
                          %pbLong                 = 503
                          %pbQuad                 = 504
                          %pbWord                 = 505
                          %pbDword                = 506
                          %pbSingle               = 507
                          %pbDouble               = 508
                          %pbExtended             = 509
                          %pbCurrency             = 510
                          %pbExtendedCurrency     = 511
                          %pbString               = 512
                          %pbFixedLengthString    = 513
                          %pbAscizString          = 514
                          %pbFieldString          = 515
                          %pbGUID                 = 516
                          %pbVariant              = 517
                          
                          %pbUserDefinedType      = 518
                          %pbArray                = 519
                          %pbObject               = 520
                          
                          %pbNumericLiteral       = 521
                          %pbStringLiteral        = 522
                          %pbNumericEquate        = 523
                          %pbStringEquate         = 524
                          
                          %pbCompilerDirective    = 525
                          %pbOperator             = 526
                          %pbKeyword              = 527
                          
                          %pbComment              = 528
                          
                          'VB6 variable types & term descriptors
                          %vbBoolean              = 529
                          %vbByte                 = 530
                          %vbConst                = 531
                          %vbCurrency             = 532
                          %vbDouble               = 533
                          %vbInteger              = 534
                          %vbLong                 = 535
                          %vbSingle               = 536
                          %vbString               = 537
                          %vbFixedLengthString    = 538
                          %vbVariant              = 539
                          
                          %vbUserDefinedType      = 541
                          %vbArray                = 542
                          %vbObject               = 543
                          %vbCollection           = 544
                          
                          %vbCompilerDirctive     = 545
                          %vbOperator             = 546
                          %vbKeyword              = 547
                          
                          %vbComment              = 548
                          
                          'Class Properties, Methods, & Events
                          %vbClass                = 549
                          %vbProperty             = 550
                          %vbFunction             = 551
                          %vbSub                  = 552
                          %vbEvent                = 553
                          
                          'TokenizerStatus equates
                          %IsPaused               = 554
                          %IsReady                = 555
                          %IsRunning              = 556
                          %IsFinished             = 557
                          %IsSearching            = 558
                          %IsEditing              = 559
                          
                          '------------------------------------------------------------------------------
                          
                          TYPE PropertyType                   'use in PropertyArray(); list of properties developed in first run through VB code
                              vbTerm AS STRING * 32
                              VarType AS LONG
                              DefaultValue AS STRING * 32
                              Comment AS STRING * 128
                          END TYPE
                          
                          TYPE MethodType                     'use in MethodArray(); find in first run through Vb code
                              vbTerm AS STRING * 32
                              ProcedureType AS LONG
                              ReturnType AS LONG
                              Arguments AS STRING POINTER
                              Prototype AS STRING * 256
                              Comment AS STRING * 128
                          END TYPE
                          
                          TYPE EventType                      'use in EventArray(); find in first run through
                              vbTerm AS STRING * 32
                              OccursOn AS LONG
                              ReturnType AS LONG
                              DefaultValue AS STRING * 32
                              Comment AS STRING * 128
                          END TYPE
                          
                          TYPE ObjectSimulatorType            'use in ClassArray(); first run through
                              Properties AS STRING * 256
                              Methods AS STRING * 256
                              Events AS STRING * 256
                              Comment AS STRING * 128
                          END TYPE
                          
                          '------------------------------------------------------------------------------
                          '   *** Globals ***
                          '------------------------------------------------------------------------------
                          GLOBAL vbProjectName AS STRING
                          GLOBAL ParseReportFileList AS STRING    'holds files to be processed by Tokenizer
                          
                          GLOBAL TokenizerStatus AS LONG          'current status of application
                          
                          GLOBAL PropertyArray() AS PropertyType
                          GLOBAL FunctionArray() AS MethodType
                          GLOBAL EventArray() AS EventType
                          GLOBAL ClassArray() AS ObjectSimulatorType
                          BTW: Rod, how big is that data file getting now?

                          Stan
                          Do not go quiet into that good night,
                          ... Rage, rage against the dark.

                          Comment


                          • #14
                            Rod is experiencing some temporary technical difficulties, and hopes to have them minimized by this weekend so he can get back to the task.

                            Rod
                            Rod
                            In some future era, dark matter and dark energy will only be found in Astronomy's Dark Ages.

                            Comment


                            • #15
                              Originally posted by Rodney Hicks View Post
                              Rod is experiencing some temporary technical difficulties, and hopes to have them minimized by this weekend so he can get back to the task.

                              Rod
                              Take care of Rod.
                              Do not go quiet into that good night,
                              ... Rage, rage against the dark.

                              Comment


                              • #16
                                Stan
                                E-mailed a new version of the dct file.

                                Not much response to the poll so follow your instincts.

                                Rod
                                Rod
                                In some future era, dark matter and dark energy will only be found in Astronomy's Dark Ages.

                                Comment


                                • #17
                                  Rod,

                                  I direct this at you because you've been doing most of the work on the dictionary.

                                  Do you think we need to make a separate entry for each possible use of a VB term? The reason I ask is what I've been finding as I work through the VB language reference. It looks like many VB terms do slightly different things depending on which built-in control/object is being referenced. The biggest example of this is ActiveX controls, but let's ignore ActiveX.

                                  So what I'm wondering is what do you think? Should we have multiple listings in the dictionary or should we list the relevant controls/objects in the Comments field? ... or maybe add a second Comments field for VB terms only?

                                  As you see, I'm feeling around in the dark on this. But we need to figure out what to do with it so the Tokenizer/Preprocessor can act intelligently... or at least not too stupidly.

                                  Stan
                                  Do not go quiet into that good night,
                                  ... Rage, rage against the dark.

                                  Comment


                                  • #18
                                    Stan

                                    Should we have multiple listings in the dictionary or should we list the relevant controls/objects in the Comments field? ... or maybe add a second Comments field for VB terms only?
                                    Somewhere along the way, when first starting on the dictionary, in one of my first dabbles, I had included an extra variable, that I had marked for future use. Then we started using it for something. So that future is behind us now.

                                    Perhaps now is the time to make a change in the dictionary file.

                                    I think that each dictionary entry(presently six fields) should have a reference to other entries by the sequential number of the entry, left blank when not needed. THOUGHT PROCESSES HALTED DUE TO INFORMATION SCARCITY.

                                    Is it possible that we make one member of our dictionary UDT another UDT?
                                    I hate to make that complication, but it might in the long run be simpler.

                                    Should we give each definition an ID? and store the ID within the dictionary?
                                    This so we can reference other definitions within definitions, so to speak.

                                    An additional string for storing related terms(example: styles for labels)

                                    This ID would only be used by the converter of course. Just thinking....:hmmm:

                                    We do have the option of setting different(additional) flags in the second and third items. Can we set it up to OR the items together?

                                    Rod
                                    Rod
                                    In some future era, dark matter and dark energy will only be found in Astronomy's Dark Ages.

                                    Comment


                                    • #19
                                      Rod,

                                      Originally posted by Rodney Hicks View Post
                                      ...
                                      Perhaps now is the time to make a change in the dictionary file.

                                      I think that each dictionary entry(presently six fields) should have a reference to other entries by the sequential number of the entry, left blank when not needed. THOUGHT PROCESSES HALTED DUE TO INFORMATION SCARCITY.
                                      It's been in the back of my mind that we may need to index the dictionary. Somewhere on one of my backups I've got a RANDOM file indexer I wrote for pbDos that runs pretty quickly. I'll see if I can find it...

                                      Is it possible that we make one member of our dictionary UDT another UDT?
                                      I hate to make that complication, but it might in the long run be simpler.

                                      Should we give each definition an ID? and store the ID within the dictionary?
                                      This so we can reference other definitions within definitions, so to speak.

                                      An additional string for storing related terms(example: styles for labels)

                                      This ID would only be used by the converter of course. Just thinking....:hmmm:
                                      All possible. We could use the physical record number as the reference ID. Then make an additional index file to make lookups faster. Adding a UDT within the current UDT might be the easiest way to handle it -- not sure.

                                      Thinking out loud -- could load the dictionary record from one file and the additional subUDT from an index file. That avoids the necessity to modify the existing dictionary file format. Then everything we need is in RAM for each record and we don't have to modify the existing dictionary format ... hmmm ... :thinking: I try to write code to open & close files at need to avoid too many open files at one time -- we'd have to leave the dictionary and the index files open, I think. File access is the slowest part of PB (if I remember my ancient benchmark readings right), but with only three or four files open at one time it shouldn't be noticable to the user.

                                      We do have the option of setting different(additional) flags in the second and third items. Can we set it up to OR the items together?

                                      Rod
                                      That may be the quickest method. I'll think about this some more.

                                      Stan
                                      Do not go quiet into that good night,
                                      ... Rage, rage against the dark.

                                      Comment


                                      • #20
                                        Stan and Rod,

                                        Do you think we need to make a separate entry for each possible use of a VB term? The reason I ask is what I've been finding as I work through the VB language reference. It looks like many VB terms do slightly different things depending on which built-in control/object is being referenced. The biggest example of this is ActiveX controls, ...
                                        I think this could be decided on at a later date, certainly something to keep in mind. It is my observation here that we simply don't have enough quality experience with converting VB code to PB to know what we should do up front to warrant these kinds of mental gymnastics before the first version of VB2PB is released. I think you all need to make a decision to go with what we have developed now and get to coding version 1.0. When the converter is released and used I'm quite confident the users will tell us what works and what doesn't and why, therefore, I would expect a large number of changes will be required from version 1.0 to version 2.0. to clean things up and make the functionality of the converter operate the way it should.

                                        Now I'm not suggesting we put out an inferior product, but the kinds of comments on the dictionary to date (while valid and should be considered) fall into the "Gee, wouldn't it be cool if the converter did THIS" syndrome and causes release dates to be pushed back further and further.

                                        I also agree with Mr. Zale's policy of no vaporware we should follow that principle. Nothing irritates me more than to point out deficiencies ABC in a software product only to be told that's going to be fixed in the next release and you will be able to XYZ too.

                                        ...but let's ignore ActiveX.
                                        Agreed.
                                        Later...

                                        JR

                                        "When governments fear the people there is liberty. When people fear the government there is tyranny." - Thomas Jefferson

                                        Comment

                                        Working...
                                        X