Announcement

Collapse
No announcement yet.

More wishes...

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

  • More wishes...

    Hello,


    1. extend inline assembler to support new PIII opcodes.
    2. allow calling API functions with inline asm (see example)
    3. Please "fix" the editor, I have lost too much code...


    example(PIII opcodes):
    Code:
      cmov[xx] instructions
      etc...
    example(calling API):
    Code:
      asm mov eax,hWnd
      asm push eax
      asm mov eax,ps
      asm push eax
      asm call BeginPaint


    ------------------
    Cheers

  • #2
    hi mark

    2. allow calling api functions with inline asm:
    this works fine already - try it and see - using asm in pb
    you can call any functions, including the api.

    [update]oh, just re-read your post - i see what you mean -
    you can't call the function by name in asm - at the moment you
    have to call the address of the function. i'm so used to doing
    this that i oversaw that's what you wanted. it'd be a useful
    shortcut.

    look at
    or http://www.powerbasic.com/support/pb...ad.php?t=17604
    for an example

    cheers

    florent



    [this message has been edited by florent heyworth (edited october 04, 2000).]

    Comment


    • #3
      Updating the IDE is a priority for us. If you have specific complaints or suggestions, please make them.

      ------------------
      Tom Hanlin
      PowerBASIC Staff

      Comment


      • #4
        Originally posted by Tom Hanlin:
        Updating the IDE is a priority for us. If you have specific complaints or suggestions, please make them.

        - A project window/explorer would be nice
        - Some 'Intellisense' as well (including type members, function parameters...)
        - I personally don't need a visual designer, but there should be a better external resource editor
        (please skip the necessity to edit the resource files before they can be used...)
        - Could the IDE use a temporary copy for compile/run, so one can save the file manually when desired?

        Regards

        Andreas



        ------------------

        Comment


        • #5
          More wishes...

          Banale, but important : Allow userdefined background color.
          I'd also like an option to have the entire screen for coding.
          An improved (!) version of PowerGen as part of the IDE.

          By 'improved' I mean:
          - Not only scanning resource files, but more dialog based ( a 'wizard' )
          - Easy reuse of code/application templates ( = static libs, right? )
          - Keeping track of the changes already made.
          - ( Dream on ... )

          Currently, PowerGen eats your code when you sleep... :-(

          Conclusion :
          More project orientation, a bit less typing. Functionality.
          But no irritating 'visual' toys.

          PB's IDE has always been poor ( then such a compiler ... ).
          I think it's not THAT bad - you can write very good code in it :-).
          Personally, I liked the one in DOS. Would always use it instead
          of Vi ( ... :^) )

          Andreas


          ------------------

          Comment


          • #6
            Hello again,


            I would like to add one more thing to my wish list...


            Allow the use of brackets around the parameters in a subroutine
            call. for example

            Code:
            mysubroutine(var1, var2)
            This is already supported but you have to put the keyword "CALL"
            infront of your subroutine. I think these brackets clean up the
            code and make it easier to read.

            What do you guys think?

            ------------------
            Cheers

            Comment


            • #7
              Mark, the CALL statement casts the code firmly into "statement" format. Likewise, omitting the parentheses does this too, by using the sub/function name as the "statement".

              However, omitting the CALL keyword and including the parentheses implies "function" format, and this syntax is confusing... it's appearance would suggest the line of code was missing a trailing expression. It may also make the compiler job a harder in determining the purpose of the line if referencing an [possibly undeclared] array or is actually a call to a Sub/Function. Conversely, it may look like the line is missing a leading assignment operator.

              ie,
              Code:
              mysubroutine(var1, var2)
              implies a trailing operator and expression:
              Code:
              mysubroutine(var1, var2) = some_expression
              or is missing an assignment operator:
              Code:
              Variable = mysubroutine(var1, var2)
              IMHO, allowing this type of syntax would lead to greater confusion. That said, I'll still pass these sugestions to R&D... it is their place to decide based on the ideas merits/disadvantages.

              To help me out here, can you tell me a good reason (or reasons) why this type of syntax would be beneficial? Thanks!

              ------------------
              Lance
              PowerBASIC Support
              mailto:[email protected][email protected]</A>
              Lance
              mailto:[email protected]

              Comment


              • #8
                For the new IDE I'd like to see a display or read-ahead for function types.

                VB does this via a tool tip type windows but it could be be displayed in the status bar or whatever.
                The IDE would have read the INC files for Declare statements and when you type

                x = MyFunction(

                the IDE lets you know what data types the funtion is expecting, so if you forget the order of prarmeters for the INSTR() fucntion or the BitBlt() API then they will display when you press the "(" key.

                Also a way to track projects so that you are encouraged to split a large program into multiple .inc and .bas files. I mean in a way that you can access them easily like a docked/removable window. having lots of .bas files open everywhere is annoying.



                ------------------

                Paul Dwyer
                Network Engineer
                Aussie in Tokyo
                (Paul282 at VB-World)

                Comment


                • #9
                  Lance, I understand your point of view but putting brackets around
                  the parameters of a subroutine does appear cleaner. Here is an
                  example...

                  Code:
                  MySubroutine varptr(buffer), StatusFlags, OtherVariable
                  Code:
                  MySubroutine (varptr(buffer), StatusFlags, OtherVariable)
                  I dunno, maybe its just me and my old habbits. Would it really
                  hurt to put this into the compiler? With all the other changes
                  requested like OOP it sounds like the compiler parsing logic
                  would have to undergo some recoding anyway.

                  While we are on the topic of compiler internals, How hard would
                  it be to allow calling API function from inline assembler code
                  link this?

                  Code:
                  asm mov eax,PS ;push PAINTSTRUCT onto the stack
                  asm push eax
                  asm mov eax,HDC ;push the device context onto the stack
                  asm push eax
                  asm call BeginPaint



                  ------------------
                  Cheers

                  Comment


                  • #10
                    Anything is possible... I'll pass the request along. An answer to "How hard..." would only be possible by an R&D team member (if they are permitted to discuss such questions that is )

                    ------------------
                    Lance
                    PowerBASIC Support
                    mailto:[email protected][email protected]</A>
                    Lance
                    mailto:[email protected]

                    Comment


                    • #11
                      (forget I posted this, I was brain dead)


                      ------------------
                      Dave
                      http://www.davidcrowell.com

                      [This message has been edited by Dave Crowell (edited October 06, 2000).]

                      Comment

                      Working...
                      X