Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Help a lazy developer!
#1
Terry posted an idea for improving QB64PE here:  https://qb64phoenix.com/forum/showthread.php?tid=2075

Basically, his idea was simple -- Add an optional parameter to CLS so you don't have to change _DEST when using it.

And hey, let's be honest, that's a GREAT idea!!   But, let's take it a step further:  How many times have you wished you could just do a simple PSET (x, y), color, optional_imagehandle?  Set a color of a pixel on an image, without having to alter source and dest to do so!

And how many other commands are there that could benefit from this type improvement?  Off the top of my head, I can think of:

CLS ,background, imagehandle
PSET (x, y), color, imagehandle
LINE (x, y) - (x,y), color, BF, imagehandle
CIRCLE (though I'm too lazy to look up all its syntax), imagehandle

Now, here's my question for you guys, and here's where you can help with some easy development tasks: Give me a list of any and all other commands which could benefit from this simple optional parameter addition. A change like this won't affect existing code at all. Your old stuff won't break. All it'll do is allow a little more flexibility to be added to new stuff, and make it just a little simpler to code things in the future. And, honestly, making such changes is more or less a trivial matter which even someone like myself can push into the repo with just a few hours work and a couple lines of code.

Wrack your brain and help list what needs this style improvement. Heck, if you're brain damaged like me, yet have a ton of free time, pop over to the wiki and scroll down the command list and see what it seems like an optional parameter could help improve.

List those ideas here, and I'll see about taking a little free time this week and next weekend, and making the changes for us and push them into the repo for folks to enjoy in future versions of QB64PE. I'm getting older, and my eyes go all crosseyed and I fall asleep scrolling up and down lists of raw documentation anymore. You guys make me a list, and I'll make what changes I can. You won't get a better offer than that for $1.29 at your local McDonalds!
Reply
#2
I like this concept - a lot. Kudos to you and Terry. In addition to CLS, PSET, LINE and CIRCLE, how bout:
PRINT
COLOR
PAINT
LOCATE
Reply
#3
Thumbs Up 
Interesting idea specially if does not render old code unusable.
b = b + ...
Reply
#4
Basically any legacy command that deals with graphics could benefit from this. I'll take some time to go through the command list too.
New to QB64pe? Visit the QB64 tutorial to get started.
QB64 Tutorial
Reply
#5
_PRINTSTRING (x,y,imagehandle),string

May I ask: If we can have output directing to image handles... why not another window?  Don't really need a complex event model in QB64 for that do we?    

Screen _newimage(W,H,mode),windowhandle       would be awesome, with windowhandle being managed for the QB64 programmer as any other image handle so pset(x,y),color,imagehandle could use the windowhandle similar to the imagehandle if making such modifications.
Reply
#6
(10-16-2023, 01:00 AM)James D Jarvis Wrote: _PRINTSTRING (x,y,imagehandle),string

May I ask: If we can have output directing to image handles... why not another window?  Don't really need a complex event model in QB64 for that do we?    

Screen _newimage(W,H,mode),windowhandle       would be awesome, with windowhandle being managed for the QB64 programmer as any other image handle so pset(x,y),color,imagehandle could use the windowhandle similar to the imagehandle if making such modifications.

Might mess up the Screen default assumptions in old code, ie having to specify a screen handle to Screen command??? I don't know, just guessing at possible obstacles.
b = b + ...
Reply
#7
_PRINTSTRING(columnrow), textExpression$[, imageHandle&][, COLOR]
10 PRINT "Hola! Smile"
20 GOTO 10
Reply
#8
Thumbs Up 
(10-16-2023, 01:51 PM)Ikerkaz Wrote: _PRINTSTRING(columnrow), textExpression$[, imageHandle&][, COLOR]

Roger that! along with KeepBackground option
b = b + ...
Reply
#9
(10-16-2023, 12:51 PM)bplus Wrote:
(10-16-2023, 01:00 AM)James D Jarvis Wrote: _PRINTSTRING (x,y,imagehandle),string

May I ask: If we can have output directing to image handles... why not another window?  Don't really need a complex event model in QB64 for that do we?    

Screen _newimage(W,H,mode),windowhandle       would be awesome, with windowhandle being managed for the QB64 programmer as any other image handle so pset(x,y),color,imagehandle could use the windowhandle similar to the imagehandle if making such modifications.

Might mess up the Screen default assumptions in old code, ie having to specify a screen handle to Screen command??? I don't know, just guessing at possible obstacles.

Overloaded subs/functions are already in use for the compiler aren't they?   It's fairly common in C/C++.  The default can just remain there. That's how the image handles would be added to other output commands, wouldn't it?
Reply
#10
I am an advocate for pedantic coding, the source code should leave nothing for guesswork, suppose someone not familiar with QB64's lazy options tries to decipher your code?
Reply




Users browsing this thread: 2 Guest(s)