Text Only | Text with Attachments

QB64.org Forum

Active Forums => QB64 Discussion => Topic started by: FellippeHeitor on January 09, 2021, 08:42:23 am

Title: IDE improvements (v1.5)
Post by: FellippeHeitor on January 09, 2021, 08:42:23 am
IDE improvements to look for in upcoming v1.5 - already available in the development build at https://www.qb64.org/portal/development-build/ (https://www.qb64.org/portal/development-build/):

SUBs dialog can now show the line count for each SUB/FUNCTION in your program:
  [ This attachment cannot be displayed inline in 'Print Page' view ]  

The right-click contextual menu now works in the Help area too (the Edit menu is now also aware that the focus is in the Help area, so Select All and Copy will work with the Help text. Hey @bplus!)
  [ This attachment cannot be displayed inline in 'Print Page' view ]  

Also, the status bar will now show the selected line count too (previously only single-line selections would show the count of characters).
  [ This attachment cannot be displayed inline in 'Print Page' view ]  

If you are on the beta-testing wagon, please try to break the new features above and report below.

Full changelog at https://github.com/QB64Team/qb64/commits/development (https://github.com/QB64Team/qb64/commits/development).
Title: Re: IDE improvements (v1.5)
Post by: FellippeHeitor on January 09, 2021, 09:51:21 am
We haven't run speed tests, so I can't attest to that. What I can tell you is that the first time you compile a project with a new installation of QB64 it will have to rebuild all libraries, so the first compilation may indeed take longer.
Title: Re: IDE improvements (v1.5)
Post by: bplus on January 09, 2021, 10:31:12 am
Quote
The right-click contextual menu now works in the Help area too (the Edit menu is now also aware that the focus is in the Help area, so Select All and Copy will work with the Help text. Hey @bplus!)

Hey! Thankyou! :)
Title: Re: IDE improvements (v1.5)
Post by: FellippeHeitor on January 09, 2021, 11:13:59 am
The IDE highlights the offending line in red, and the status bar shows this:

  [ This attachment cannot be displayed inline in 'Print Page' view ]  

Is it something different you're referring to?
Title: Re: IDE improvements (v1.5)
Post by: FellippeHeitor on January 09, 2021, 06:25:08 pm
XP virtual machine.
Title: Re: IDE improvements (v1.5)
Post by: zaadstra on January 10, 2021, 07:19:23 am
Quote from: FellippeHeitor on January 09, 2021, 11:13:59 am
The IDE highlights the offending line in red, and the status bar shows this:

  [ This attachment cannot be displayed inline in 'Print Page' view ]  

Is it something different you're referring to?

Silly question that may have been asked before (a thousand times ...)

Is it possible that the IDE highlinghts not only the line, but also where it 'sees' an issue?  In the screenshot example it is quite clear, but there are occasions that I really don't see what/where the problem is.
Title: Re: IDE improvements (v1.5)
Post by: luke on January 10, 2021, 08:39:51 am
What you're asking for is column information, on top of the current row information.

I tried to add this myself a while back but couldn't see a way to do it. Fellippe might have further insights though.
Title: Re: IDE improvements (v1.5)
Post by: Petr on January 10, 2021, 01:46:10 pm
Hi. We just discovered a possible problem with why _MOUSEMOVEMENT doesn't work. To test _MEMSOUND, I downloaded both 32-bit and 64-bit versions from Github, and that now turned out to be a good thing. In this thread https://www.qb64.org/forum/index.php?topic=3475.msg127918#msg127918  we discovered a problem with _MOUSEMOVEMENT with @OldMoses. The big help is that it works with the 32-bit version of the IDE, but not with the 64-bit version. I estimate that the wrong data type for the 64-bit version will be used somewhere.
Title: Re: IDE improvements (v1.5)
Post by: Pete on January 10, 2021, 01:50:26 pm
@zaadstra

Provide the column info, no! QB64 is already too picky. Just look at the above example. While it is clear the coder FORGOT to capitalize the "W" in "world" there is NO reason QB64 shouldn't just pint it!

Pete :D
Title: Re: IDE improvements (v1.5)
Post by: GTC on January 11, 2021, 09:35:23 am
Quote from: luke on January 10, 2021, 08:39:51 am
What you're asking for is column information, on top of the current row information.

I think this would be very useful. Of all the programming languages I've used, I find Basic the most obtuse when it comes to the interpretation of compilation error messages, and there are occasions when I can sit for some time trying to see the error, whereas a positional flag would save that time (and frustration).

This request has my strong vote.
Title: Re: IDE improvements (v1.5)
Post by: Dav on January 11, 2021, 09:47:21 am
v1.5 seems to clear up an odd IDE color problem I had in v1.4-32 bit.  I never did report on it, but sometimes  variable names would be partly colored, like in this screen cap below.  Doesn't happen in v1.5.

- Dav

Title: Re: IDE improvements (v1.5)
Post by: Dimster on January 11, 2021, 09:48:14 am
Does the present error detection detect multiple errors on the same line or does it just report upon the first error encountered?
Title: Re: IDE improvements (v1.5)
Post by: FellippeHeitor on January 11, 2021, 09:57:47 am
Quote from: Dav on January 11, 2021, 09:47:21 am
v1.5 seems to clear up an odd IDE color problem I had in v1.4-32 bit.  I never did report on it, but sometimes  variable names would be partly colored, like in this screen cap below.  Doesn't happen in v1.5.

- Dav

We did make some adjustments, but that corner case in the picture is surprising. Good to know it's covered!
Title: Re: IDE improvements (v1.5)
Post by: FellippeHeitor on January 11, 2021, 09:58:09 am
Quote from: Dimster on January 11, 2021, 09:48:14 am
Does the present error detection detect multiple errors on the same line or does it just report upon the first error encountered?

Error reports in the IDE currently only indicate the offending line.
Title: Re: IDE improvements (v1.5)
Post by: Dav on January 11, 2021, 11:03:40 am
Yes, I'm still using 32-bit QB64, and still enjoying  32-bit Win7. I wouldn't mind getting a 64-bit OS some day, for testing purposes, but I've been fine and dandy using 32-bit.

- Dav
Title: Re: IDE improvements (v1.5)
Post by: RhoSigma on January 11, 2021, 11:28:38 am
As there's a lot movement in the IDE development lately, I'd like to remind you about this proposal, already made before v1.4 became offical:
https://www.qb64.org/forum/index.php?topic=2103.msg113469#msg113469

Maybe v1.5 can make it possible.
Title: Re: IDE improvements (v1.5)
Post by: Petr on January 11, 2021, 12:22:58 pm
Just a little thing, Fellippe. I downloaded the latest IDE from Github for the _MOUSEMOVEMENT test (this works great now). The IDE tells me that it will compile to the folder where QB64 is. OK. Then check the option to compile to the source folder. A message appears stating that it will be compiled to the source folder. It's alright. BUT, if after this option you don't at least make a space in the source code, you just don't take any action, you just change the option and choose to run, the new compilation won't take place.
Title: Re: IDE improvements (v1.5)
Post by: FellippeHeitor on January 12, 2021, 02:15:49 pm
Quote from: Petr on January 11, 2021, 12:22:58 pm
Just a little thing, Fellippe. I downloaded the latest IDE from Github for the _MOUSEMOVEMENT test (this works great now). The IDE tells me that it will compile to the folder where QB64 is. OK. Then check the option to compile to the source folder. A message appears stating that it will be compiled to the source folder. It's alright. BUT, if after this option you don't at least make a space in the source code, you just don't take any action, you just change the option and choose to run, the new compilation won't take place.

It is an expected behavior, Petr, but thanks for bringing it to light, I'll maybe add a more informative message.

PS: @Petr the latest dev build pushed today has this behavior reworked. Please try it when you can and let me know.
Title: Re: IDE improvements (v1.5)
Post by: Petr on January 13, 2021, 02:22:22 pm
Hi Fellippe. Is it this version? https://github.com/QB64Team/qb64  I see more information texts, but is possible having this output: Open blank IDE, write there just CLS, click to RUN - START. Untitled.exe is created and then run. Now Save your work as test.bas. Click to RUN - MAKE EXE ONLY. You give info, that untitled exe is already created - but your program name now is different. It is just detail, i know. I don't want to be an eternal troublemaker and grumbler ... of course otherwise the IDE is absolutely great!!!
Title: Re: IDE improvements (v1.5)
Post by: FellippeHeitor on January 13, 2021, 02:28:34 pm
The latest version is always at https://www.qb64.org/portal/development-build/

I'll see about that detail - but you gotta agree that your program was already compiled as is, even though the name is different, right? 😉

The latest version will not only say it already created the EXE, but will also link to it in the status area, so you can just click it to go there.
Title: Re: IDE improvements (v1.5)
Post by: Petr on January 13, 2021, 02:37:44 pm
Yes, you're right :) I'll look again, this time at the correct version. You have a lot of patience with me :)
Title: Re: IDE improvements (v1.5)
Post by: Petr on January 13, 2021, 02:53:17 pm
Now the IDE monitors the previously described problem and compiles after changing the folder, without user interference to the program. Good job!
Title: Re: IDE improvements (v1.5)
Post by: Petr on January 14, 2021, 09:54:44 am
Hi, @FellippeHeitor  I remembered one more thing if you wanted to deal with it... but it's really a small thing. Field name letters when used with LBOUND or UBOUND are still different. This is still such a small fly in the IDE. I'm running to work with _MEMSOUND. :)
Title: Re: IDE improvements (v1.5)
Post by: FellippeHeitor on January 14, 2021, 09:56:07 am
Proper array name capitalization in UBOUND/LBOUND calls is my greatest IDE defeat to this day! 😂
Title: Re: IDE improvements (v1.5)
Post by: FellippeHeitor on January 14, 2021, 09:57:32 am
@RhoSigma I promised to look, but ended up forgetting since the issue wasn't mentioned in the repository. I'm having a look at it now.

Edit: Looking at the code you provided, it seems troublesome to deal with already. For example, this:
Code: QB64: [Select]
  2. a$="Hello "+_
  3.    "World "+_
  4.    "!!"
  6.  

would not be turned into this:
Code: QB64: [Select]
  2.     a$="Hello "+_
  3.        "World "+_
  4.        "!!"
  6.  

But instead into this:
Code: QB64: [Select]
  2.     a$="Hello "+_
  3.     "World "+_
  4.     "!!"
  6.  

You see how the intentional indentation added by the user gets lost immediately. I, for one, use line continuation for the exact purpose of string concatenation (with the occasional IF line that gets too long). So I'll write something like:

Code: QB64: [Select]
  1.             IF TotalSUBs = 0 THEN
  2.                 l$ = l$ + "  Type  Arguments"
  3.                 lSorted$ = l$
  4.                 lSized$ = lSized$ + " Line count  Type  Arguments" + sep
  5.                 lSortedSized$ = lSortedSized$ + " Line count  Type  Arguments"
  6.             ELSE
  7.                 num$ = LTRIM$(STR$(TotalLines(TotalSUBs)))
  8.                 IF pInsideDECLARE THEN num$ = "external"
  9.                 lSized$ = lSized$ + CHR$(195) + CHR$(196) + pn$ + "  " + _
  10.                           CHR$(16) + CHR$(2) + SPACE$(9 - LEN(num$)) + num$ + "  " _
  11.                           + psf$ + CHR$(16) + CHR$(16) + pargs$ + sep
  12.             END IF

And I'd hate to have it automatically turned into:
Code: QB64: [Select]
  1.             IF TotalSUBs = 0 THEN
  2.                 l$ = l$ + "  Type  Arguments"
  3.                 lSorted$ = l$
  4.                 lSized$ = lSized$ + " Line count  Type  Arguments" + sep
  5.                 lSortedSized$ = lSortedSized$ + " Line count  Type  Arguments"
  6.             ELSE
  7.                 num$ = LTRIM$(STR$(TotalLines(TotalSUBs)))
  8.                 IF pInsideDECLARE THEN num$ = "external"
  9.                 lSized$ = lSized$ + CHR$(195) + CHR$(196) + pn$ + "  " + _
  10.                 CHR$(16) + CHR$(2) + SPACE$(9 - LEN(num$)) + num$ + "  " _
  11.                 + psf$ + CHR$(16) + CHR$(16) + pargs$ + sep
  12.             END IF

Keep in mind the IDE wouldn't go as far as detecting these subtleties.

If you have any suggestions on how to proceed, I'm open to hear them.
Title: Re: IDE improvements (v1.5)
Post by: RhoSigma on January 14, 2021, 12:49:55 pm
Thanks for looking into this Fellippe,

my thinking about it was to do something like a sub-formatter instead of running the concatenated line through the auto-formatter.

When the auto-formatter is processing a sourcefile, then I assume it always know the current indention level at any arbitrary line, i.e. it knows how many spaces need to be added in front of each line.

Now when the auto-formatter detects a line continuation (underscore at end of line), then it should enter some kind of sub-loop, in which it just adds the known amount of spaces right in front of the lines (I mean each single line, no need to concatenate the full line). This sub-loop is repeated until the line continuation ends (no more underscore at line end), then it falls back to the regular auto-formatting until the next continuation is found.

I'm not looking for a complete formatting, but just for correct indention, to avoid the disruption of the block alignment.

Code: QB64: [Select]
  1. IF this THEN
  2.     'the following is hand-formatted
  3.     a$ = "Hello " +_
  4.          "World " +_
  5.          "!!"
  7.  

If I later need to add e.g. another IF block, then the following will happen,

Code: QB64: [Select]
  1. IF this THEN
  2.     IF that THEN
  3.         'the following is hand-formatted
  4.     a$ = "Hello " +_
  5.          "World " +_
  6.          "!!"
  7.     END IF
  9.  

Now here it's easy to see, so I'd probably hand-adjust it again, but imagine a big block with 100 lines or even more which are out of my sight in the moment when I insert the new IF, then I'll probably forget about them.

Title: Re: IDE improvements (v1.5)
Post by: SMcNeill on January 14, 2021, 01:13:53 pm
I’ve never played around with underscore continuation too much, but the issue might have to do with continued spaces from line to line.
     DO_
     NOT x

Now, is that a DO NOT x statement, or a call to sub DONUT x??  Where’s the space in that code?  How the heck do we deal with those?  I honestly don’t know, and aren’t at a PC to check at the moment.

If there’s no concern of lost spaces from line to line, then the solution might be as simple as having the IDE strip off any leading spaces on line two, and then auto-indenting to the proper place to line up as before.

With that, you’d end up with:

Code: QB64: [Select]
  1.  IF this THEN
  2.     'the following would be auto-formatted
  3.     a$ = "Hello " +_
  4.     "World " +_
  5.     "!!"

Though I’d suggest adding one additional indent level to continued lines, just to make them stand out a little differently.
Title: Re: IDE improvements (v1.5)
Post by: STxAxTIC on January 14, 2021, 01:19:40 pm
Quote from: SMcNeill on January 14, 2021, 01:13:53 pm
     DO_

If your line is so long that this is necessary, you're DOing wrong.
Title: Re: IDE improvements (v1.5)
Post by: SMcNeill on January 14, 2021, 01:24:04 pm
Quote from: STxAxTIC on January 14, 2021, 01:19:40 pm
If your line is so long that this is necessary, you're DOing wrong.

It’s just an example to highlight the concern.  I certainly don’t think anyone is using it for such short lines.  Feel free to imagine 200 characters of stuff in front of that DO, and then see it leads or trails spaces.
Title: Re: IDE improvements (v1.5)
Post by: RhoSigma on January 14, 2021, 01:26:15 pm
Quote from: SMcNeill on January 14, 2021, 01:13:53 pm
If there’s no concern of lost spaces from line to line, then the solution might be as simple as having the IDE strip off any leading spaces on line two, and then auto-indenting to the proper place to line up as before.

No, that's exactly what causes the loss of user intended allignment, instead we just need to add the proper indention, BUT WITHOUT stripping any leading whitespace in the 1st place.

BTW - Thanks for the DONUTs :)
Title: Re: IDE improvements (v1.5)
Post by: RhoSigma on January 14, 2021, 02:46:18 pm
@FellippeHeitor
Just see at GitHub, you've also a branch trying to reduce disk activity by using internal buffers. The changes there look to be in a very early stage for now with just the Open-/CloseBuffer routines, so it's not too late to mention this.

If you've not already done so, you should have a look into my Libraries Collection into the SB-Storage folder. It's a comprehensive buffer system with loading/saving/append/insert data or whole files or other buffers, you can freely seek around, set bookmarks, search for regular data/text or delimiters, copy&paste, read/write line based or as raw data (even memblocks and so everything which you can put into _MEM), can convert between LNX/MAC and WIN line endings. Of course, a complete documentation is included.

This buffer system might be just the tool you need for your efforts. If so, then feel free to incorporate it into the QB64 distribution.
Title: Re: IDE improvements (v1.5)
Post by: FellippeHeitor on January 14, 2021, 02:48:06 pm
Thanks, Rho. Will check it.

I'm aiming at something pretty simple, since all QB64 does is PRINT # to files - my goal with that research is to reduce actual disk writes and perform them all at once at the end. May not even make it into 1.5.
Title: Re: IDE improvements (v1.5)
Post by: RhoSigma on January 14, 2021, 03:42:51 pm
Then I'm sure it's exactly what you want. Just look on the SimplyText.bas example.

EDIT:
On a closer look I see you depend on handle numbers rather than different names for each buffer, which makes sense if I think about it as replacement for dozens of open files.

I'll setup a special edition of the library, which allows for handles. Already got an idea how, shouldn't take too long,
will let you know here....
Title: Re: IDE improvements (v1.5)
Post by: FellippeHeitor on January 14, 2021, 08:00:38 pm
Here's what to look for/test/try to break in the latest dev build generated on 2021-01-15, from git e4d987a:


Full changelog at https://github.com/QB64Team/qb64/commits/development (https://github.com/QB64Team/qb64/commits/development), as usual.
Title: Re: IDE improvements (v1.5)
Post by: RhoSigma on January 15, 2021, 05:11:19 am
Nice new ASCII chart, but broke it :)

- open ASCII chart
- hover mouse over any char (don't click it)
- press ENTER, would expect to trigger highlighted default button <Cancel>, but select the char instead

- open ASCII chart
- select any char via mouse or keyboard
- press TAB once to make <Insert CHR$> the default button
- press ENTER to trigger the default button <Insert CHR$>
- will insert the select char only, but not the CHR$ code
- here <Insert CHR$> works only when clicked with the mouse
Title: Re: IDE improvements (v1.5)
Post by: FellippeHeitor on January 15, 2021, 06:39:38 am
Thanks, Rho. I will be looking into it today.
Title: Re: IDE improvements (v1.5)
Post by: OldMoses on January 15, 2021, 11:32:32 am
This new ASCII chart function seems to eliminate the need to fool around with CHR$ at all, except if you want to access characters numerically.

I replaced my CHR$(248) with just inserting the degree character in quotes, and it worked fine in my program. It is easier than looking up the code and typing Alt 0248.
Title: Re: IDE improvements (v1.5)
Post by: FellippeHeitor on January 15, 2021, 11:35:16 am
For sharing your code, I recommend you keep CHR$(248), as extended ascii characters may eventually get corrupted, depending on the website.

The old version of the ASCII chart would only add the actual character, the new one will allow you to search for the glyph you're after and insert CHR$(code) easily.
Title: Re: IDE improvements (v1.5)
Post by: OldMoses on January 15, 2021, 05:23:23 pm
Quote from: FellippeHeitor on January 15, 2021, 11:35:16 am
For sharing your code, I recommend you keep CHR$(248), as extended ascii characters may eventually get corrupted, depending on the website.

The old version of the ASCII chart would only add the actual character, the new one will allow you to search for the glyph you're after and insert CHR$(code) easily.

Point taken. I noticed that trying to insert a degree character in Notepad or on the forum would result in a null type character, e.g. ø
Title: Re: IDE improvements (v1.5)
Post by: Mad Axeman on January 15, 2021, 05:45:06 pm
If you go to help and click on Math (being pedantic here, to us in the UK that should have a 's' on the end) and then just click on <OK> without entering anything wouldn't it be better to just close the box without entering
'ERROR -- NULL string; nothing to evaluate'
on the program line?
Title: Re: IDE improvements (v1.5)
Post by: FellippeHeitor on January 15, 2021, 05:56:01 pm
Spoiler: math box completely redone. Will post tonight.
Title: Re: IDE improvements (v1.5)
Post by: FellippeHeitor on January 15, 2021, 07:12:35 pm
Please grab tonight's build from https://www.qb64.org/portal/development-build/ (https://www.qb64.org/portal/development-build/) (from git 6af5bca) and look for the following:

- New Tools menu, that groups the new ASCII Chart, the Math Evaluator, the Quick Keycode and the RGB Mixer:
    - ASCII Chart dialog tweaked with attention to @RhoSigma's report of keyboard shortcuts.
        - Clearer indication that the chart has focus.
        - Double-click now is used to insert multiple characters in the code edit area without closing the box.


    - Math Evaluator interface rewritten.
        - Same functionality/core as before.
        - Retrieves last expression used in the same session.
        - Retrieves the current selection from the edit area, if any.


    - RGB Color Mixer is now part of the Tools menu, and can be invoked freely.
        - No need to be typing an _RGB statement to use the mixer.


    - New "Update Help" dialog.
        - I don't know how many of you ever go to Help->Update All Pages, to fetch new content from the wiki, but if you ever did, you remember how ugly it used to be. Now there's a dialog just for that.
Title: Re: IDE improvements (v1.5)
Post by: OldMoses on January 16, 2021, 06:37:44 am
Here's a screen shot of something that effectively ended the ability to input code.

The computer had gone to sleep with ddf755e running and a program in it. I woke it up this morning loaded another program, scrolled around and jumped from SUB to SUB for a bit and then went to enter a comment and got this warning along with a simultaneous message from Windows Defender about threat detection.

  [ This attachment cannot be displayed inline in 'Print Page' view ]  

It seems to work ok after restarting the IDE
Title: Re: IDE improvements (v1.5)
Post by: FellippeHeitor on January 16, 2021, 07:16:48 am
Likely due to the way QB64 continuously writes to disk while editing/compiling is taking place, it has been known to not work well with system suspend/hibernation states.

Also, I hope you have whitelisted QB64 and the whole folder/subfolder structure where it's located in your antivirus/antimalware software, as recommended.

Thanks for reporting.
Title: Re: IDE improvements (v1.5)
Post by: SMcNeill on January 16, 2021, 07:38:43 am
Here’s an idea for the ASCII chart, while you’re tweaking things:  Add an area to insert multiple characters at one.

For example, let’s say someone wants to make a double-line ASCII box.  Currently, they’d have to open the ASCII chart once to insert the top left corner character, then once for each “=“ style character, and then once for the top right character..  Instead, it’d be much easier to build that line in the ASCII chart itself, and then click the INSERT CHARACTER button to add them all at once.

(And Insert CHR$, in the above case, might break down to CHR$ + STRING$ combinations.  CHR$(179) + STRING$(10, 182) + CHR$(180), or whatever those actual values might be.)
Title: Re: IDE improvements (v1.5)
Post by: FellippeHeitor on January 16, 2021, 09:03:52 am
Double click now works to add multiple characters, as described/demonstrated. Thanks for the suggestions.
Title: Re: IDE improvements (v1.5)
Post by: RhoSigma on January 16, 2021, 03:30:26 pm
That's good done @FellippeHeitor,

I like that move to introduce the new "Tools" menu to clean out and reserve the "Help" menu for real help related entries. The ASCII chart also looks better now and the behavior is as expected. Maybe another tweak can be done to the new double-click feature...

Current behavior:
- a double-click always resets the default button to "Insert char" and then inserts the char into the edited code

Better behavior:
- if I TAB to change the default button to "Insert CHR$" and then double-click a char, should keep the default button "Insert CHR$" and insert CHR$(...)
- maybe better it should insert CHR$(...) + , for concatenation (cause it's easier to delete the final +, rather then afterwards insert it between all the inserted CHR$(...)
- even better better, add a checkbox to allow the user to choose, if he wants the + or not


For your other working place regarding disk usage, I've now finished the special edition of the SB-Storage system and updated my Libraries Collection download on the page linked in my signature.
This edition allows the use of handles to dynamically create new buffers, so it should be more suitable for your needs. The easiest workflow could be like the example below, so it would be more or less just a replacement of the file based commands with the buffer related commands, you said you want it simple :)

Code: QB64: [Select]
  1. '$INCLUDE: 'QB64Library\SB-Storage\stringbuffer.bi'
  2.  
  3. '--- somewhere during program init
  4. '-----
  5. REDIM SHARED MyBuffers$(0)
  6. REDIM SHARED MyFileNames$(0) 'DIM whatever number you need
  7.  
  8. '--- buffer equivalent to opening a file
  9. '-----
  10. bufHandle% = 0 'this is like a file number
  11. InitBuf MyBuffers$(), bufHandle%: MyFileNames$(bufHandle%) = "Test.txt"
  12.  
  13. '--- writing to buffer, synonym for PRINT #..., hence line breaks will
  14. '--- be added automatically, there are also functions to write raw data,
  15. '--- which would be a PUT #... synonym
  16. '-----
  17. WriteBufLine MyBuffers$(), bufHandle%, "Some text."
  18. WriteBufLine MyBuffers$(), bufHandle%, "Some concatenated text. This is buffer #" + LTRIM$(STR$(bufHandle%))
  19. '...
  20.  
  21. '--- finally save all buffers
  22. '-----
  23. FOR i% = firstBuf% TO lastBuf%
  24.     BufToFile MyBuffers$(), i%, MyFileNames$(i%)
  25. NEXT i%
  26.  
  27. '--- there's no synonym to close a buffer, simply re-init any buffer to
  28. '--- discard the old data and clear all markers (if any), after InitBuf()
  29. '--- the buffer is always like a fresh file opened for OUTPUT
  31.  
  32. '$INCLUDE: 'QB64Library\SB-Storage\stringbufferWH.bm'
  33.  
  34.  
Title: Re: IDE improvements (v1.5)
Post by: FellippeHeitor on January 16, 2021, 03:35:44 pm
Quote from: RhoSigma on January 16, 2021, 03:30:26 pm
Maybe another tweak can be done to the new double-click feature...

Current behavior:
- a double-click always resets the default button to "Insert char" and then inserts the char into the edited code

Better behavior:
- if I TAB to change the default button to "Insert CHR$" and then double-click a char, should keep the default button "Insert CHR$" and insert CHR$(...)
- maybe better it should insert CHR$(...) + , for concatenation (cause it's easier to delete the final +, rather then afterwards insert it between all the inserted CHR$(...)
- even better better, add a checkbox to allow the user to choose, if he wants the + or not

See, the 'Insert character' button is the default button - meaning it will be triggered when no other button has focus upon hitting ENTER. When the chart has focus, the default button will be triggered, regardless of which button you temporarily had focus on before with TAB - that merely changed focus, not the default dialog button after all (I'm following Windows' logic here, I believe). That said, I believe the double-click shortcut should have a single behavior, really.

I will be checking your buffer code, but again, no guarantees. Thank you for working on it!
Title: Re: IDE improvements (v1.5)
Post by: FellippeHeitor on January 16, 2021, 03:45:14 pm
To further extend on my reasoning to keep it as it is, take this dialog:

  [ This attachment cannot be displayed inline in 'Print Page' view ]  

OK is the default button, as indicated by the blue outline. That's equivalent to our COLOR 15 "< >" button indicators.

If you have focus in the text area, ENTER triggers OK.

If you tab to any button and hit ENTER, you'll be triggering whichever button you had focus on - OK, Cancel or Browse.

As soon as you click back into the text field though, no matter which button had focus before: ENTER will trigger the OK button, as it's the default.
Title: Re: IDE improvements (v1.5)
Post by: SMcNeill on January 16, 2021, 03:53:12 pm
To expand on what I mentioned before:  Add one more field to the ASCII popup, as a “preview-input” area, rather than a double-click auto-insert into the code. 

Think of it like in your image above where it reads “calc” — an input box for the keypress(s).  Then it’s easy to toggle between inserting the actual character(s), or the CHR$/STRING$ equivalent into the code with a single click.
Title: Re: IDE improvements (v1.5)
Post by: FellippeHeitor on January 16, 2021, 04:39:08 pm
Thanks for your input, Steve.
Title: Re: IDE improvements (v1.5)
Post by: FellippeHeitor on January 18, 2021, 08:35:36 pm
New development build available today (https://www.qb64.org/portal/development-build/), built from git c46b441. Here's the list of the latest commits: https://github.com/QB64Team/qb64/commits/development
Text Only | Text with Attachments