Menu

How to change workflow?

Anobium
2026-09-14
2026-09-14
  • Anobium

    Anobium - 2026-09-14

    Here's the complete post:


    Great question and worth sharing.

    I've been learning much so far, creating a .1 sec timer, accessing EEprom, using the 16x2 LCD, accessing the 16 to 1 multiplexer and so on. I split my code such that the constants reside in a const.h file, the variables definitions in a varlst.h file, IO definitions in a iodef.h file AND last but not least, all my subroutines and functions are in a Func.h file. Needless to say, most of my debugging occurs in the func.h file so that when it comes time to compile, I am still in the .H file forgetting to return to the main .gcb file before compiling... This is a royal pain in the a** so I have to ask: Can a settings be used to specify the default file when compiling??? This would prevent a lot of swearing which peaves off my wife. If possible, save my wife's sanity and possibly be able to specify which file to compile as the main.....

    This is genuinely one of the most common "gotchas" for anyone who splits GCBASIC code across multiple .h files. A few techniques that help:

    1. Add #ignorecompile to the files you never want compiled directly. The #ignorecompile directive is used to control whether a source file can be compiled. Drop it at the top of const.h, varlst.h, iodef.h, and Func.h. If you (or your editor) ever hit "compile" while one of those tabs is active, GCBASIC will refuse and point you back to the real main file instead of silently building the wrong thing.
      → Docs: https://gcbasic.sourceforge.io/help/__ignorecompile.html

    2. If you're using the SynWrite-based IDE (GCB@Syn), set up a "Project" and nominate your main file. Users who've hit this exact problem found that setting your files up as a project and selecting your main file as the one with the #chip directive resolves the issue — once a file is marked as the project's main, the compile command targets it regardless of which tab has focus.

    3. Keep #chip only in your main .gcb file, never in the .h files. If you are using the GCB@SYN IDE you must put #chip in the main program — and since GCBASIC needs #chip to know what it's building for, a .h file without it will fail fast (loudly, before wasting your time) rather than quietly compiling nonsense.

    4. Rename your main file so it's impossible to miss. Something like AAA_main.gcb sorts to the top of your file list/tabs, so your eye (and your mouse) naturally lands on it first instead of whichever .h tab you were last debugging in.

    5. Hard-code a build task in VS Code / GCode. If you're using the GCode IDE (VS Code-based), you can define a task in tasks.json that always compiles a specific file, so it doesn't matter which tab has focus when you hit compile:

    {
        "version": "2.0.0",
        "tasks": [
            {
                "label": "Compile Main (hardcoded)",
                "type": "shell",
                "command": "${env:GCBASIC_INSTALL_PATH}\\GCBASIC.exe",
                "args": [
                    "${workspaceFolder}\\YourMain.gcb",
                    "/NP",
                    "/S:use.ini",
                    "/F:N",
                    "/P:",
                    "/DO"
                ],
                "options": {
                    "cwd": "${workspaceFolder}"
                },
                "problemMatcher": [],
                "group": {
                    "kind": "build",
                    "isDefault": true
                },
                "presentation": {
                    "showReuseMessage": false,
                    "clear": true,
                    "reveal": "always",
                    "panel": "shared",
                    "close": false
                }
            }
        ]
    }
    

    Swap YourMain.gcb for your actual main file's name. What the flags do:

    Flag Purpose
    /NP Don't pause on errors — required for IDE-driven builds so the process doesn't hang waiting for a keypress.
    /S:use.ini Load settings from a specified file rather than use the defaults — points the compiler at your project's use.ini.
    /F:N Forces a fresh compile every time rather than trusting cached output — matters most while actively debugging.
    /P: Batch file used to call the programmer — left empty so this task compiles only and doesn't try to flash the chip.
    /DO Use the .build folder for debugger operations — keeps intermediate output out of your source folder.

    Save it as gcstudio\vscode\tasks.json. Once it exists, press F4 to open the task menu — your new task will show up in that list alongside the built-in GCB tools. Pick it once from the F4 menu, and from then on it becomes the top entry — so every time after that, F4 followed by Enter (or just hitting F4 and it being pre-selected) runs your hardcoded compile, no matter which .h tab you were just in.

    Between these you should be able stop it from happening at all. Your wife thanks you in advance. 😄

    Anobium


    What are you techniques to improve the workflow ?

     
  • philip leboeuf

    philip leboeuf - 2026-09-14

    Well, that was a good try. Using the #ignorecompile in the .h files gives, as an example:
    Cannot find I:!GCbasic\Alarm 5\SysRoutine.gcb
    Also, the "#ignore" part is in blue but the "compile" part is in white. (#ignorecompile)

    Also, what is SynWrite? I am using the GCSTUDIO.EXE ide.

    Next, I have seen .json files all over the place but, have no idea what it's all about? I did follow your directions, made a tasks.json file and placed it in the GCstudio/vscode folder as well as in my project folder but it seems to not do anything.

    The last time I worked (employed) on PIC microcontrollers was in 2001. I suffered a Burn-out because of all the codes I wrote , Remote car starters/alarms/starter kill units (7 or more different varieties for several companies) which were all in my head. I had the ability of seeing all the codes in my head and rarely used flowcharts or notes. I could see which page a specifc code appeared in and which line etc. Maybe this is why I suffered burn-out. I started writing the software in September and the products needed to be out by November (for the christmas rush) and I almost never had bugs. Programming to me was as easy as writing a letter. In the past few years, I regained some ability to program once again but no complex software as before. I used to write computer bulletin boards within a week (before the internet became popular.) Programming languages like FORTH, Multi-tasking Forth etc, in a short period of time. How I wish it were that easy today. Maybe old age has something to do with it as well (72yrs)

    Anyways, GCBasic is really powerful compared to the 1980's and 1990's so it appears I have a lot to learn. Discovering things here and there. Anyways, thanks for your time and replies. Maybe I'll look up that SynWrite IDE to see what it's all about.

    Phil

     

    Last edit: philip leboeuf 2026-09-14
    • Anobium

      Anobium - 2026-09-14

      Is #ignore working ? does something else no compile?

      Ignore Synwrite. It is the legacy and unsupported text editor.

      Your own tasks go in : gcstudio\vscode\tasks.json
      Be very careful deleting system json files.

      Similar age here. Take care with health.

      My advice. Ignore SynWrite.

       

Log in to post a comment.