Announcement

Collapse
No announcement yet.

Finding stuff in API includes, an easy solution

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

  • Finding stuff in API includes, an easy solution

    I have found it a a challenge to find which include file a specific declare is in or even it it is in multiple include files. I created a solution, a PB console app, which allows to you scan a folder for every .bas and .inc file in that folder for some text and then display a list of files it is found in.

    After seeing Garys GBSearch, I strongly recommend using it instead. Mine is too simple in comparison.
    Last edited by Chris Boss; 20 May 2019, 09:59 AM.
    Chris Boss
    Computer Workshop
    Developer of "EZGUI"
    http://cwsof.com
    http://twitter.com/EZGUIProGuy

  • #2
    For example, if I run the app scan for %WM_COPYDATA in less than 2 seconds I get a list of files where it is found in:

    DDT.inc
    WindowsX.inc
    WinUser.inc

    Now I can simply load each find in the PB IDE and do a Find Text search in the IDE and I now know where it is.

    I don't always like to include a significant number of API includes in my apps if I don't have to. If I only make a few API calls, I often like to find the declares in the include file and copy and paste into my app. By adding one include in an app, it may link to other includes and you can end up having dozens of includes run through the compiler. By just using what you need instead, the compiler compiles apps signficantly faster.

    Also some times you may have problems when your app gets very large. You can push the compiler to the limits if too many include files are used. By just copying what you need into your app or into a "commonly used API's" include of your own, then you make things much easier to manage.


    Chris Boss
    Computer Workshop
    Developer of "EZGUI"
    http://cwsof.com
    http://twitter.com/EZGUIProGuy

    Comment


    • #3
      Hi Chris!

      You might also like gbSearchLite, that I released a few years back. Here's an image with the same search you performed. It previews the lines containing the search term.

      Click image for larger version

Name:	pb_2109.jpg
Views:	164
Size:	41.0 KB
ID:	781397?

      You can adjust the output to show a list of files, the line numbers where the content is found, as well as show lines above and below the matching lines. There are a number of other options as well.

      Comment


      • #4
        Nice, Gary.
        Chris Boss
        Computer Workshop
        Developer of "EZGUI"
        http://cwsof.com
        http://twitter.com/EZGUIProGuy

        Comment


        • #5
          Downloaded it and it is impressive ! Nice job Gary.

          Chris Boss
          Computer Workshop
          Developer of "EZGUI"
          http://cwsof.com
          http://twitter.com/EZGUIProGuy

          Comment


          • #6
            Chris, thanks!

            But, your post did make me see one new feature that might be useful - copying the matching code lines - enabling a user to find a declaration and copy it for pasting in the IDE.

            I've not had the need for it myself, but I can see that others might. I'll see about adding that feature.

            Thanks for the suggestion.

            Comment


            • #7
              Chris,
              Another thought. I do not use a thread for the search. So if you try to start at C:\ and drill down the whole drive, gbSearchLite will become non-responsive until the search is over. I only do such a large-scale search occasionally - when I've no idea which folder contains the file containing the search term - so I've not been motivated to change over to a thread.

              I just tried a search like that. It took just about 2 minutes to find the 22 files containing %WM_CopyData. I'll put the thread search on my GoDo list, but for no more than I've done that broad a search the change may not happen soon!

              Comment


              • #8
                Chris: Is there any particular reason you do not use Windows' built in search for this? It is perfectly capable of searching inside a file, as well as within a specific directory?.
                I am legally blind. Please forgive any typos. I do try and catch as many as I can.

                Comment


                • #9
                  I have been using Gotcha off of Pierre's site

                  Comment


                  • #10
                    Gary,
                    My recommendation would be to have checkboxes to prefix the search term.
                    Selecting "DECLARE FUNCTION" as the prefix:
                    [_] No prefix
                    [/\] FUNCTION prefix
                    [_] TYPE prefix
                    [_] UNION prefix
                    [_] SUB prefix
                    [_] THREAD prefix
                    [_] MACRO prefix
                    [_] INTERFACE prefix
                    [/\] DECLARE prefix to a prefix

                    If the User doesn't know what the API command is then the prefix would provide a simple and more accurate search. The User would not have to type in each possibility one at a time. This method would provide much faster and better help when a search term is referenced in numerous files.

                    Search term DrawFocusRect

                    What is searched for DECLARE FUNCTION DrawFocusRect

                    Yes, a threaded search would be awesome.

                    Comment


                    • #11
                      Gary's GBSearch is far superior to my little console app. Wish I knew about it before. I never had a big need until I had to do some custom programming for someone and their app was including over 150 INC files, much of it WIN32 API include files. I didn't know where to start to find stuff.

                      As a rule, when I write apps I try to use as few include files as possible, especially the WIN32. For example, I started EZGUI back in the days of PB 5.0 and when I got to PB 6.1 I stopped using each new iteration of WIN32 inc files. The older versions of Powerbasic had WIN32 API include files which were much simpler than today's. Later versions, Powerbasic switched to the layout of the C++ header files in the Windows SDK, which is a nightmare when it comes to finding stuff. I stuck with the older inc files and simply manually updated them when a change need to be made or something was missing. The layout of the later WIN32 inc files is terribly confusing and just add one inc file and you may end up having a dozen or more added unexpectedly because that inc file has references to other inc files.

                      Now when my customers who use EZGUI need to add something from the WIN32 API, I strongly recommend they find what they need and just copy the bare minimum of declares statements/constants from the original WIN32 files and paste them into their app or into a single include file with commonly used API's. This makes compile time much faster and less issues with a new iteration of WIN32 includes breaking something.

                      For Powerbasic DDT users, it is similar IMO. Just use the DDT include files and then when you need something not in them, copy from the WIN32 include files what you need into the DDT include file or your own special commonly used WIN32 API include file.

                      Powerbasic is an amazingly fast compiler, but if you bog it down with too many include files you may be surprised at how long it takes to compile an app. If done right most, even large, apps should be able to compile in 2 or 3 seconds. If it takes 5, 10 or 15 or more seconds to compile, often the culprit is too many WIN32 API files. The later versions with Powerbasic are too much like the C headers in the SDK so they link in other include files, which line in other ones and so on.

                      Now maybe something Gary could add to GBSearch is to be able to generate a dependency tree for a BAS file. Select a BAS file and then show all the WIN32 (and other) includes referenced and build a tree if say one inc file references another inc file and that one references another inc file and so. That would be very enlightening. I think many would be surprised when they saw how many WIN32 inc files are actually getting pulled into PB when you compile your app.

                      Some might find this interesting:

                      When I compile EZGUI 5.0's main DLL, it is over 40,000 lines of code. It only references in my code the following WIN32 include files:

                      win32.inc
                      comctrl.inc
                      EZcomdlg.inc (my custom version of comdlg.inc)
                      richedit.inc

                      Now when I compile it , it is almost instantaneous. The compiler reports back:

                      "Compile time: 0.9 seconds"

                      the total # of lines, including WIN32 inc files it reports as 63,144, which is little over 20,000 extra lines of code.

                      Now that is actually very small (WIN32 stuff I mean), since I use an old set of WIN32 include files from PB 6.1 which I customized over the years.

                      Now if I were to recompile using the latest WIN32 I would imagine the number of lines of code compiled could add up to a significant amount more.

                      Not bad compiling something like EZGUI 5.0 Pro runtime which is as intense as one may get in using the WIN32 API. I doubt many have as many different API calls in their apps as does the EZGUI runtimes. To compile in less than 1 second is amazing!

                      It is only when I have do work for someone else who uses more current WIN32 includes that I have a nightmare of a time. Too many WIN32 includes can make a PB app compile in 10, 50 or 20 seconds, when if done right with less include dependencies it might compile in 1 second.

                      20 seconds may not sound like a lot today, but if you are like me where I compile, run, test and edit, compile, run and test over and over again, it does add up.



                      Chris Boss
                      Computer Workshop
                      Developer of "EZGUI"
                      http://cwsof.com
                      http://twitter.com/EZGUIProGuy

                      Comment


                      • #12
                        Maybe you should use a faster computer...

                        PowerBASIC 10 for Windows
                        Copyright (c) 1996-2011 PowerBasic Inc.
                        Englewood, Florida USA
                        All Rights Reserved

                        Primary source: C:\Users\JOSERO~1\AppData\Local\Temp\Untitled1.bas {215027 total lines}
                        Target compilation: Untitled1.EXE
                        Compile time: 0.3 seconds, at 43005400 lines/minute

                        And I'm sure that many PBer's will have a computer much better than mine.
                        Forum: http://www.jose.it-berater.org/smfforum/index.php

                        Comment


                        • #13
                          I use a low cost refurbished HP business desktop PC. Only 4 GB ram, older dual core CPU and onboard intel Video. Unlike most programmers today I don't use a bleeding edge PC.
                          I compiled someone else's app which referenced over 100 WIN32 API include files and it took a very long time to compile.

                          So yes, you are probably right that many PCs used by todays programmers it may not be an issue.
                          Last edited by Chris Boss; 19 May 2019, 02:38 PM.
                          Chris Boss
                          Computer Workshop
                          Developer of "EZGUI"
                          http://cwsof.com
                          http://twitter.com/EZGUIProGuy

                          Comment


                          • #14
                            As a general rule it appears that the more global values and string literals and COM interfaces and resources and arrays you have in your app the longer it takes to compile.

                            Comment


                            • #15
                              Choosing the right files to include is also important to EXE size and speed of compile.
                              (since we have the master of include files José Roca online, he might help us out with some advice)

                              A simple bas file exaple below,
                              Code:
                              #COMPILE EXE
                              #DIM ALL
                              #INCLUDE "Win32Api.inc"
                              
                              'Test.EXE   7 168 2019-05-19 06:30     with PB standard include
                              'Test.EXE 17 408  2019-05-19 06:31    with Jose Roca include
                              
                              FUNCTION PBMAIN () AS LONG
                                 MSGBOX "Hi world"
                              END FUNCTION

                              Comment


                              • #16
                                Originally posted by Gary Beene View Post
                                Chris,
                                Another thought. I do not use a thread for the search. So if you try to start at C:\ and drill down the whole drive, gbSearchLite will become non-responsive until the search is over.
                                You shouldn't need to use a thread, you should just need to give the OS some breathing room in your main loop.

                                I am legally blind. Please forgive any typos. I do try and catch as many as I can.

                                Comment


                                • #17
                                  Originally posted by Mikael T View Post
                                  Choosing the right files to include is also important to EXE size and speed of compile.
                                  Unless you are using a dated version of PB, the latest version will only compile what it actually uses out of the include and any size difference should be negligible.
                                  I am legally blind. Please forgive any typos. I do try and catch as many as I can.

                                  Comment


                                  • #18
                                    Originally posted by Chris Boss View Post
                                    I use a low cost refurbished HP business desktop PC. Only 4 meg ram, older dual core CPU and onboard intel Video. Unlike most programmers today I don't use a bleeding edge PC.
                                    Pretty much the last versions of Windows that would run with 4MB of RAM were Windows 95/8.

                                    Low-spec systems are mandatory for use as test systems, but should never be used for a development system. It is too costly in time wasted.

                                    I am legally blind. Please forgive any typos. I do try and catch as many as I can.

                                    Comment


                                    • #19
                                      I'm sure he means GB, not MB. I'm with Chris here - when I was most "active", I always used a standard, mediumfast machine for development instead of a super-duper rocket computer to see problems with redraw and search, etc. at an early stage. Very easy to miss such problems if one use super-duper latest machines that few people have anyway. Compile time in PB has never been a problem, no matter what we are using. Have seen some terrible "professional" applications with lagging and redraw problems, etc. over the years - easy to see that they were developed on some extreme computers and not tested enough on average user machine.

                                      Comment


                                      • #20
                                        Originally posted by Mikael T View Post
                                        Choosing the right files to include is also important to EXE size and speed of compile.
                                        (since we have the master of include files José Roca online, he might help us out with some advice)

                                        A simple bas file exaple below,
                                        Code:
                                        #COMPILE EXE
                                        #DIM ALL
                                        #INCLUDE "Win32Api.inc"
                                        
                                        'Test.EXE 7 168 2019-05-19 06:30 with PB standard include
                                        'Test.EXE 17 408 2019-05-19 06:31 with Jose Roca include
                                        
                                        FUNCTION PBMAIN () AS LONG
                                        MSGBOX "Hi world"
                                        END FUNCTION
                                        When using my includes, use #include "windows.inc" instead of "win32api.inc", that I only have for compatibility with the PB includes. "Windows.inc" has better granularity.
                                        Forum: http://www.jose.it-berater.org/smfforum/index.php

                                        Comment

                                        Working...
                                        X