kind of works? reading multiple mice: any c programmers want to look at this?

[mnrvovrfc]

:
Eventually I would like to create some equivalent functions in QB64 to run my old TI programs. The biggest challenge will be CALL SOUND!

CALL CLEAR. Wait, wrong computer LOL, on TRS-80 Model III had to clear the screen to get it away from "large" character mode, no wonder Family Computing Magazine and others were full of the "PRINT CHR$(147)" at one end and "CLS" at the other. Of course, that could be done with "WIDTH" in M$QB and descendants. The "CALL CLEAR" on Texas Instrument computer, however, was something I couldn't believe when I read about it a long time ago. Really, no button assigned to clear the screen? Maybe the screen didn't have that much to display anyway. Must have been even smaller than VIC-20 then.

Imagine small children being taught to program in BASIC and could just press a button labelled "CLEAR", or could even do a control-key combination to do it, but the selected few on a certain computer have to pretend it's COBOL.

EDIT 24 sept: not sure which character code was required printed for TRS-80, but the CHR$(147) was for Commodore 64. I'm sorry if I mislead anybody about this.

[madscijr]

:
Eventually I would like to create some equivalent functions in QB64 to run my old TI programs. The biggest challenge will be CALL SOUND!

CALL CLEAR. Wait, wrong computer LOL, on TRS-80 Model III had to clear the screen to get it away from "large" character mode, no wonder Family Computing Magazine and others were full of the "PRINT CHR$(147)" at one end and "CLS" at the other. Of course, that could be done with "WIDTH" in M$QB and descendants. The "CALL CLEAR" on Texas Instrument computer, however, was something I couldn't believe when I read about it a long time ago. Really, no button assigned to clear the screen? Maybe the screen didn't have that much to display anyway. Must have been even smaller than VIC-20 then.

Imagine small children being taught to program in BASIC and could just press a button labelled "CLEAR", or could even do a control-key combination to do it, but the selected few on a certain computer have to pretend it's COBOL.

Ha! I don't recall being bothered that my TI computer had a key to clear the screen. But it was my first computer so I had nothing to compare it to. The same with the program editor, didn't it limit you to one line at a time? What a pain it was to go back to that years later! 

Yes, I think maybe TI cut costs on the TI99/4A by using a smaller keyboard with less keys, and they had to eliminate some common keys? Cheap keyboards seem to have been a popular way to keep costs down back then, remember those awful membrane keyboards on the Atari 400 and Timex Sinclair 1000? That might have been okay on a Speak n Spell, but not for a computer you'd be typing on for hours!

[madscijr]

Yeah, we've come a long way. Some of those older BASIC languages had advantages. Atari Basic had a way to change ascii characters into custom 8x8 characters, very easily. I wish we still had that with QB. I don't miss the line numbers from TI days, that's for sure. Programming games like 4-player monopoly on those limited memory systems was a great way to become adept at optimization. Only bad habits is possibly the use of single character variables and few remark statements.

We have indeed come a long way! I too do not miss line numbers and one or two-letter variable names - on the Commodore 64, 2 characters was all you got! You could type longer names, but only the first 2 characters uniquely identified a variable. (I think that was a step up from the TI, wasn't standard TI BASIC limited to one letter?)

I am glad that QB64 at least supports line numbers, which makes it a lot easier to run and/or port these old programs.

And the editor! On the TI, I don't think you could edit an existing line, all you could do was list it, and then re-type the whole thing with your changes! The C64's full screen editor was a step up, where you could move around the screen with the cursor keys and type your changes over the existing code & just press ENTER to save your changes. 

Of course the C64 still didn't let you scroll up and down through your program like QBasic's editor! In HS computer class we learned Pascal (on Apple IIs), which opened my eyes that there was a much better way to do things, both with the editor and all the nice structured programming stuff. (And if you got to class early, you could get dibs on one of the newer Apple IIes which had a nicer keyboard and an 80-column card! Next to the 2e, the Apple II Plus was a dog! LoL)

In the 90s when I finally moved to PC and started playing with Qbasic & QB45, it was SO nice to be able to ditch the line numbers, use descriptive label & variable names, scroll up & down through my programs, AND use functions/procedures/UDTs and all the nice structured programming stuff that Pascal had!

In any case, the TI & C64 got me started in programming, that's for sure. 

Well if this multi-controller project works out it will be a nice addition for gammers. Have you thought through what syntax may be needed to handle the job? Maybe the usb ports could be used as identifiers. _Mousebutton(1, 2) as an array? In otherwords something to distinguish who clicked what, etc.

I think the first program in this thread that "sort of works" addresses that. Try running it or look at the code and you'll see, it is able to distinguish between mice.

[mnrvovrfc]

The Texas Instruments cartridge BASIC, if I remember from the book I read, for "IF... THEN" allowed only a line number right after "THEN", and therefore encouraged spaghetti code. It didn't support colon anywhere neither. Timex Sinclair also didn't like colons but at least it enabled "K" cursor right after "THEN" was keyed in, so "GOTO" was required but almost anything else like "GOSUB", "PRINT" etc. The British computer also allowed graphic characters typed in directly into a string literal to "PRINT", something I deeply wished my Tandy Color Computer 3 was able.

[Pete]

Line numbers would drive folks bats on those older systems like TI. I used to do write mine by the 20s, so I could insert lines later, if needed. My friend used to just keep rewriting his code. Argh, poor guy. I recall GOTO was a main tool back then, as subs and functions were not in existence. No labels, either. Speaking of pasta programming, weird that some languages used "POP" to get the user out of a GOSUB. POP would act as a fake RETURN and unstack the stack. With a POP POP here and a POP POP there. Steve McNeill had some code, 1-0-1-0-0-0... Sorry, I get carried away sometimes, often in a tight white jacket. It's probably due to writing all those line numbers back in the 1980's. That, or maybe it was something to do with all those controlled substances in the 70's.

Pete

[madscijr]

I foresee "racing" issues if you take that approach.
Pete

Yeah, I think it will be quite a problem. Give me a couple of days to see about this way of unregistering the window and then re-registering it with the callback as part of its registration. That may or may not be the solution.

OK, I would like to pursue this route, because think it doesn't make sense for a raw input API to have to require its own Windows infrastructure, if it's really just pulling in data from HIDs. What if the dx and dy (change in mouse coordinates when it's moved) can still be read without needing a Window?

The other route is, if we can't use QB64's window, can we send the window handle to our QB64 graphic output routines, so our QB64 drawing commands can still be used?

Barring that, currently the RawMouse example uses DrawText to output to the screen, what is the Windows API way to simply plot a pixel or draw a rectangle in x color? Or a bitmap? If we can do that, we can turn it into more friendly functions that take the same parameters as the existing QB64 drawing commands, so coding it is simpler.

[SpriggsySpriggs]

@madscijr
It isn't a problem with the API. It's a problem with the fact that QB64 makes its own window that isn't setup to accept callbacks. Just assume most issues you will face is due to how QB64 was mostly designed to use internal functions and not external. External stuff is basically a side effect of the C backbone. What would be great is if right now you focus more on making a C version that does everything you want and then come back to change it over to QB64.

[madscijr]

@madscijr
It isn't a problem with the API. It's a problem with the fact that QB64 makes its own window that isn't setup to accept callbacks. Just assume most issues you will face is due to how QB64 was mostly designed to use internal functions and not external. External stuff is basically a side effect of the C backbone. What would be great is if right now you focus more on making a C version that does everything you want and then come back to change it over to QB64.

Well that's my question - whether I do it in C or do it inside QB64 set up with those events, I still need to draw graphics to the program window. Since currently we can't get QB64 and the raw input code seeing the same window, we must draw the graphics in whatever way that can access it. Currently the demo code uses DrawText, what is the API function to draw a color rectangle, so we can draw a few colored rectangles and let the mice move them around?

[SpriggsySpriggs]

I would just Google some of the drawing functions for Windows. Google is good at finding MSDN pages.

[madscijr]

I would just Google some of the drawing functions for Windows. Google is good at finding MSDN pages.

That's what I did (I included those links a few posts up). What I found is really low level and without concrete examples. They talk about things beyond window handles, stuff that a Windows C++ programmer would understand. I started googling drawing graphics examples in c for windows, and found some, but need to go through it all. A few mention SDL2, OpenGL and other libraries, I'm just looking for the most basic library-less way to draw a rectangle, so I imagine that would be a Windows API function. I'll have to read through all that stuff and see if I find something.