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.


Messages - GTC

Pages: [1] 2 3 4
1
QB64 Discussion / Re: Limit of COM9 is anachronistic and problematic
« on: January 16, 2021, 06:58:58 am »
Quote from: Mad Axeman on January 16, 2021, 06:50:53 am
[...] I'm not sure if it's a QB problem or my program. I'll have to do a bit more playing around and see whats going on

I get the impression that COM port handing within QB64 is brittle. As mentioned, an associated bug report is on GitHub.

Thanks for the tests!

2
QB64 Discussion / Re: Limit of COM9 is anachronistic and problematic
« on: January 16, 2021, 06:55:49 am »
Quote from: Mad Axeman on January 16, 2021, 05:47:34 am
I've got another laptop here running (don't laugh!) Vista.

I've got tower PCs with Win 3.1, 95, 98 and XP. Not sure how boot-able they all are.

My lifelong procedure has been never to update Windows in place, but to buy a new PC with the latest version on it already.

I sat on XP for as long as possible and now I'm sitting on on 7 64-bit. I hated what I saw with 8 and I like 10 even less.

(BTW: Scuttlebut is that MS considers Windows development a money-losing thing nowadays and some pundits posit that they -- or some MS partner -- may port the GUI to some form of Unix.)

3
QB64 Discussion / Re: My QB64 wish list
« on: January 16, 2021, 03:27:52 am »
Thanks for that!

It's more extensive than the Wiki list: https://www.qb64.org/wiki/ERROR_Codes

4
QB64 Discussion / My QB64 wish list
« on: January 16, 2021, 02:23:44 am »
If there's a wish list for future releases of QB64 then I can't find it here.

Apart from the implementation of ON COM (mentioned elsewhere), I would love to see the equivalent of VB's Err.Description:

Quote
The Err.Description provides details of the error that occurs. This is the text you normally see when an error occurs e.g. “Type Mismatch” The Err. Number is the ID number of the error e.g. the error number for “Type Mismatch” is 13.

Maybe  _ERRORTEXT (ErrorNumber)

5
QB64 Discussion / Re: Limit of COM9 is anachronistic and problematic
« on: January 15, 2021, 07:04:18 pm »
Quote from: Mad Axeman on January 15, 2021, 05:55:37 pm
I'm opening ports higher than 9 without problem.

 OPEN "COM" + port$ + ":9600,N,8,1,BIN,CS0,DS0" FOR RANDOM AS #1

where port$ can be 30+ on my laptop. I wrote a small routing for checking openable ports from 1 to 255 without problems

What OS are you using?

I'm using Win 7 and it gives me error 68 (device unavailable) if I go over 9. OK for 9 and under.

EDIT: Case in point -- I added a PCI-type dual serial port to my tower PC. The driver/Windows designated the new ports as COM11 and COM12. QB64 gave me error 68 on those so I had to use Device Manager to renumber those ports to COM2 and COM4, whereupon QB64 was happy.

This may be another manifestation of my other report about COM ports -- now classified on GitHub as a bug.

6
QB64 Discussion / Re: Limit of COM9 is anachronistic and problematic
« on: January 15, 2021, 04:53:23 am »
Thanks Fellippe. Would you kindly flag this to his attention.

7
QB64 Discussion / Limit of COM9 is anachronistic and problematic
« on: January 14, 2021, 08:30:57 pm »
@Fellippe

Regarding:

Quote
QB64 can open any COMn port number from 1 to 9.

This is my request that the upper limit of 9 ports be replaced with Windows' own limit of 255.

These days, plug-n-play hubs, etc, create port numbers above 9 and QB64's artificial limit of 9 is a nuisance.

Thanks.

8
QB64 Discussion / Re: IDE improvements (v1.5)
« 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.

9
QB64 Discussion / Re: Just want to say thanks to the QB64 team.
« on: January 10, 2021, 07:38:10 am »
Just noticed this thread. I agree 100% with the sentiments expressed here.

10
QB64 Discussion / Re: Bizarre behavior from OPEN COM:
« on: January 07, 2021, 12:14:37 am »
Quote from: luke on January 06, 2021, 11:21:13 pm
I notice the original code uses RANDOM, but the working code uses BINARY. @GTC are you able to confirm which of the two changes is the one that causes the problem?

I have also opened a github issue https://github.com/QB64Team/qb64/issues/99 to track this.

As per my OP, "BTW: the open mode -- random or binary -- makes no difference to the result in my environment."

Nor does the mode make any difference to Fellippe's revised version.

The determining factor in my tests is the presence or absence of CD0, DS0 in the open attributes string. See my notes about the points I have labeled as (a) and (b) above.

11
QB64 Discussion / Re: Bizarre behavior from OPEN COM:
« on: January 06, 2021, 10:29:06 pm »
UPDATE: I see that the the notes in Help for OPEN COM says, inter alia:

Quote
(a) If any optional CD, CS, DS or OP timeouts occur the OPEN will fail or port access will stop. Try 0 to ignore.   

Quote
(b) Four commas are required after the Speed, Parity, Bits, and Stopbit, even if none of the Options are used.

I tried (b) the four commas (i.e place holders for null items) but that made no difference. The OPEN still failed with Error 64 -- Bad file name. File name contains illegal characters or exceeds 12 characters.

So seems that either note (b) is wrong, or it is not implemented correctly in the compiler/runtime executable.

Note (a) seems to imply that there is some inconsistency in the Windows handling of COM ports that needs to be accommodated.

12
QB64 Discussion / Re: Bizarre behavior from OPEN COM:
« on: January 06, 2021, 10:05:08 pm »
Many thanks Fellippe. Very helpful to me.

I have played around with your code sample and it seems the problem relates to the presence or absence of items CS0,DS0 (CTS and DSR) which relate to flow control.

My devices specify flow control = none and in the QB64 Help for OPEN COM it shows those items as [options] -- which they are in plain vanilla Basic, too, so I would not expect to have to use them if they are options. You might like to look into that at the compiler level as to why they are generating those specific runtime errors when they are not mandatory items.

Meantime, I'll see if I can get the devices to talk via COM ports which specify CS0 and DS0 in their OPEN statements.



13
QB64 Discussion / Re: Output folder for .EXE files
« on: January 06, 2021, 09:38:44 am »
Quote from: FellippeHeitor on January 06, 2021, 09:06:00 am
First time compilation will trigger a one-time warning in the next version:
 

GTC likes this.

14
Programs / Re: Is there a way to copy data from windows and paste into a running program?
« on: January 06, 2021, 09:35:52 am »
As an aside to this, the output of Windows CMD commands can be piped to the clipboard, for instance:

SHELL "CMD/C DIR | CLIP"

15
QB64 Discussion / Re: Output folder for .EXE files
« on: January 06, 2021, 07:53:58 am »
Quote from: bplus on December 01, 2020, 11:46:59 pm
We need to rubber stamp the answer to this one because every new person to QB64 asks.

Under the Run Menu of the QB64 IDE (editor) put a bullet next to "Output EXE to Source Folder"

@FellippeHeitor: I have a better idea. Make that the default setting. Let people turn it off if it doesn't suit them.

Pages: [1] 2 3 4