1
QB64 Discussion / Re: problem with the mouse
« on: February 19, 2022, 03:09:50 am »
Yes bplus... what happens is understandable but it seems a little strange behavior
BASIC for the modern era.
News:
Listen to QB64 Report!
Our podcast on all things QB64 is out now. Listen at
http://podcast.qb64.org
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
2
QB64 Discussion / Re: BEEP makes program load faster
« on: February 19, 2022, 02:59:38 am »This issue was fixed already by @FellippeHeitor on 26-Sep-2021 (Issue #187 at Github), hence it should not longer be a problem within the latest stable release 2.0.2 from 7-Nov-2021. You can get it by clicking the big 2.0.2 banner right at the head of this forum page.
interesting! at this point a routine would be useful to ascertain the presence of the sound card on the pc.
And maybe somewhere there is already and it would be enough just to know where it is!
3
QB64 Discussion / Re: problem with the mouse
« on: February 16, 2022, 09:07:37 am »
Thanks SMcNelly, to avoid surprises so it's even better!
The problem is not yet completely solved but I believe that the road to a solution passes from here
The problem is not yet completely solved but I believe that the road to a solution passes from here
4
QB64 Discussion / Re: problem with the mouse
« on: February 16, 2022, 07:15:48 am »
Thank you Richard, very kind
I didn't expect to have to insert a corrector on the X / Y axes, also because the mouse range doesn't take into account the title bar and the window borders.
It also seemed that correcting the position was a clumsy fallback: you should know the reason for each behavior before "correcting" an unexpected result.
Probably if windows were set in some particular way also the corrector should be varied (maybe he means this SMcNell). For example, in my case, I have to put "26" and not "27".
However I believe that the argument has been useful to all :)
I didn't expect to have to insert a corrector on the X / Y axes, also because the mouse range doesn't take into account the title bar and the window borders.
It also seemed that correcting the position was a clumsy fallback: you should know the reason for each behavior before "correcting" an unexpected result.
Probably if windows were set in some particular way also the corrector should be varied (maybe he means this SMcNell). For example, in my case, I have to put "26" and not "27".
However I believe that the argument has been useful to all :)
5
QB64 Discussion / problem with the mouse
« on: February 16, 2022, 06:06:28 am »
Good morning / good evening to all
Can someone explain the mouse behavior?
At every pressure of CTRL+a (but also any other combination or key) the cursor, instead of staying still where it is, moves on the X and Y axes (mostly upwards).
Why? And how to avoid this?
Thank You...
Can someone explain the mouse behavior?
At every pressure of CTRL+a (but also any other combination or key) the cursor, instead of staying still where it is, moves on the X and Y axes (mostly upwards).
Why? And how to avoid this?
Thank You...
Code: QB64: [Select]
- j$=inkey$
6
QB64 Discussion / Re: Shell Copy (small bug ?)
« on: January 21, 2022, 06:05:40 pm »
Maybe I play all the residual reputation (if I ever have one in here) insisting a little more.
I have been attending this forum for many years and I do not seem to have ever broken the netiquette.
I have always had words of esteem and appreciation not only for the competence but also for the human welcome and respect that you breathe.
I have never pretended to teach anything to anyone (not even to a hypothetical user who reasonably perhaps knows less than me), let alone to some of you clearly many experts.
I repeat, I thought (and frankly I still do) that sharing information (this too) was useful. Thats all!
All right... one of the cardinal principles of everything - just everything - is that no one is perfect and everyone can make mistakes.
Everybody.
Excuse my naivety.
P.S. I don't know the meaning of the idiomatic phrase at the head of Cobalt's post (in my language there is no such saying), but I assume that perhaps it is better not to know it.
P.S. 2 - Don't ban me for so little... I will still need you :)
I have been attending this forum for many years and I do not seem to have ever broken the netiquette.
I have always had words of esteem and appreciation not only for the competence but also for the human welcome and respect that you breathe.
I have never pretended to teach anything to anyone (not even to a hypothetical user who reasonably perhaps knows less than me), let alone to some of you clearly many experts.
I repeat, I thought (and frankly I still do) that sharing information (this too) was useful. Thats all!
All right... one of the cardinal principles of everything - just everything - is that no one is perfect and everyone can make mistakes.
Everybody.
Excuse my naivety.
P.S. I don't know the meaning of the idiomatic phrase at the head of Cobalt's post (in my language there is no such saying), but I assume that perhaps it is better not to know it.
P.S. 2 - Don't ban me for so little... I will still need you :)
7
QB64 Discussion / Re: Shell Copy (small bug ?)
« on: January 21, 2022, 05:15:13 pm »
Well! In this case I was not asking for a solution, I was pointing out a fact.
And "stupidly" I thought it could be useful to someone.
About the solution was intuitive. Yes, but only after understanding that "+" disturbs the interpreter. Normally why should I worry about the folder name affecting the result of the routine?
Anyway thanks for your attention.
And "stupidly" I thought it could be useful to someone.
About the solution was intuitive. Yes, but only after understanding that "+" disturbs the interpreter. Normally why should I worry about the folder name affecting the result of the routine?
Anyway thanks for your attention.
8
QB64 Discussion / Re: Shell Copy (small bug ?)
« on: January 21, 2022, 05:04:25 pm »
:) I did it so that the documentation was complete :)
The case is simple: SHELL COPY (which also has other critical issues) does NOT work if the folder in which it operates ends with the "+" sign.
I can also imagine why: the compiler, when translating from bas text, does not distinguish that "+" from a concatenation mark.
I would have needed to know because it would have saved a lot of effort.
It's not a big problem, after all it was enough to know it.
Code: QB64: [Select]
The case is simple: SHELL COPY (which also has other critical issues) does NOT work if the folder in which it operates ends with the "+" sign.
I can also imagine why: the compiler, when translating from bas text, does not distinguish that "+" from a concatenation mark.
I would have needed to know because it would have saved a lot of effort.
It's not a big problem, after all it was enough to know it.
9
QB64 Discussion / Shell Copy (small bug ?)
« on: January 21, 2022, 03:53:17 pm »
Maybe I guess it's a small bug that is good to know (find out I'm worth hours of debuggin)
Put the files in a folder, then compile and run "test_code.bas".
You will get "target.bas".
Now rename the folder, adding the "+" sign. For example from "c:\folder" to "c:\folder+"
Run again "test_code.bas".
Shell Copy doesn't work!
Put the files in a folder, then compile and run "test_code.bas".
You will get "target.bas".
Now rename the folder, adding the "+" sign. For example from "c:\folder" to "c:\folder+"
Run again "test_code.bas".
Shell Copy doesn't work!
10
QB64 Discussion / Re: Waiting at the end of the compilation
« on: January 18, 2022, 05:01:41 am »
Thank you, RhoSigma.
With the transition to version 2.x I had encountered problems with recursive calls to functions (1.x version).
It was difficult to remedy (also because with version 1.x everything worked wonderfully).
The solution was a different approach to things.
I compiled directly with QB64 and the pause does not occur.
The only warning that appears - not blocking - is the one I attach.
How should I interpret this report?
I also tried to change the names of variables and procedures but the warning remains.
With the transition to version 2.x I had encountered problems with recursive calls to functions (1.x version).
It was difficult to remedy (also because with version 1.x everything worked wonderfully).
The solution was a different approach to things.
I compiled directly with QB64 and the pause does not occur.
The only warning that appears - not blocking - is the one I attach.
How should I interpret this report?
I also tried to change the names of variables and procedures but the warning remains.
11
QB64 Discussion / Re: Waiting at the end of the compilation
« on: January 17, 2022, 02:30:47 pm »
Thank You Petr,
I'll be honest: I understood almost nothing of your answer. My problem! I'm not that far ahead of computer science...
But it seems useful for everyone to further specify the following:
I don't use national unicode characters (just to maintain maximum compatibility everywhere).
I use the Dav editor and compile in the way of the editor: F5! Obviously after indicating the location of QB64. The only command added is "-c".
Some programs (usually small or very small ones) compiles them and runs them without waiting. Many others do not.
There are no reasons why one can understand the reason.
Discouraged by the results, at this point, I have to compile from command line with a batch file. The command string is taken from the QB64 wiki, so nothing fancy.
The result obtained is the same.
An important clue may be that until version 1.5 of QB64 this problem had never arisen. In fact, I tried to compile the same file NC_06.bas with QB64 v.1.5 and the execution started immediately!
I read here on the forum that changing the code is a very complex operation (I believe it!) so I can not expect that those who could do it, but it seems useful that we know about this small but boring inconvenience.
Maybe who knows... at the bottom of the source code there is a simple pause instruction to be deleted...
I'll be honest: I understood almost nothing of your answer. My problem! I'm not that far ahead of computer science...
But it seems useful for everyone to further specify the following:
I don't use national unicode characters (just to maintain maximum compatibility everywhere).
I use the Dav editor and compile in the way of the editor: F5! Obviously after indicating the location of QB64. The only command added is "-c".
Some programs (usually small or very small ones) compiles them and runs them without waiting. Many others do not.
There are no reasons why one can understand the reason.
Discouraged by the results, at this point, I have to compile from command line with a batch file. The command string is taken from the QB64 wiki, so nothing fancy.
The result obtained is the same.
An important clue may be that until version 1.5 of QB64 this problem had never arisen. In fact, I tried to compile the same file NC_06.bas with QB64 v.1.5 and the execution started immediately!
I read here on the forum that changing the code is a very complex operation (I believe it!) so I can not expect that those who could do it, but it seems useful that we know about this small but boring inconvenience.
Maybe who knows... at the bottom of the source code there is a simple pause instruction to be deleted...
12
QB64 Discussion / Re: Waiting at the end of the compilation
« on: January 16, 2022, 05:05:46 pm »
Wait press any key with command line in a file batch:
d:\qb64\qb64.exe -c %cd%\NC_06.bas -o %cd%\NC_06.exe
NC_06.bas is a complex program with many lines.
I use DavsIDE as an editor environment and also with it waits for the press of a key.
As an editor environment I use DavsIDE and also with it waits for the press of a key simpler (or very simple) programs, on the other hand, are executed immediately after compilation.
If I load the programs into the QB64 editor after compilation, usually but not always, the execution starts... I don't understand the logic !!
d:\qb64\qb64.exe -c %cd%\NC_06.bas -o %cd%\NC_06.exe
NC_06.bas is a complex program with many lines.
I use DavsIDE as an editor environment and also with it waits for the press of a key.
As an editor environment I use DavsIDE and also with it waits for the press of a key simpler (or very simple) programs, on the other hand, are executed immediately after compilation.
If I load the programs into the QB64 editor after compilation, usually but not always, the execution starts... I don't understand the logic !!
13
QB64 Discussion / Waiting at the end of the compilation
« on: January 16, 2022, 12:51:27 pm »
Hello!
How do you tell the compiler not to stop when the compilation is finished waiting for you to press a key?
How do you tell the compiler not to stop when the compilation is finished waiting for you to press a key?
14
QB64 Discussion / Re: Top of the screen
« on: January 15, 2022, 04:43:52 pm »15
QB64 Discussion / Re: Top of the screen
« on: January 15, 2022, 04:20:52 pm »
yes, it's possible, but I don't know how to translate it into code