Down key bug in IDE for 10.203

[Crivens]

Gernot, what have you done with the IDE? I cannot now use the down arrow key!!!!! All other arrow keys work fine.

Ach. Was just about to settle down to a good afternoon of GLB too! Is there a way to backout a GLB upgrade? Otherwise will have to switch to the laptop which is a touch annoying...

Fast upgrade soon maybe?

Cheers

[Crivens]

Also just noticed that the files list can use the down key but not the up key. Erm...

Plus the down key in the keypad (numlock off) doesn't work either in the code editor.

Cheers

[MrTAToad]

Yes,. down arrow key is a blorked...

[MrTAToad]

The zip file created could be used to go back a version...

[Crivens]

Something else I noticed while testing is when I am using CREATESCREEN/USESCREEN.

Basically I use createscreen and then usescreen. The user can select to clear the usescreen and I use drawrect to do that. Yesterday that was fine and it blacked out the usescreen. Now though it doesn't work.

Interestingly when I blank the usescreen with drawrect it gets rid of anything drawn to the usescreen since the createscreen. But keeps the original background. Something like that. Either way if I use clearscreen before the createscreen then using drawrect to black it all out does actually work again. Possibly because my old screen had not been drawn with showscreen before I used createscreen. So a showscreen should work before a createscreen too?... Yes that's true. So now createscreen takes whatever is in the backbuffer and uses that as a backdrop that isn't part of the main screen?

Is an interesting side effect though. My routine was like a paint drawing function. Without clearing the screen then it looks like you can draw directly onto the background picture and if you save the image it does not include the background picture. A bit like layers in a paint package. And then you can take what's drawn and place it over a different background picture. Nice. Something to remember for the future I'm sure...

Don't call it a bug then, but rather an interesting new feature to know about incase anyone is also confused in the future.

Cheers

[Kitty Hello]

Down-key and update warnings are serious. I'll fix ASAP. Tonight.

The CREATESCREEEN should make a screen that is black + transparent. Does it contain parts of the back buffer? That would be a bug then. Use drawrect to be safe.

[Crivens]

Cool.

Yeah it contains the back buffer. My createscreen is smaller than the actual screen if it helps. Interesting, I just tested it again and it isn't blacking it out. I used showscreen and clearscreen first just incase... I'll change back to just the clearscreen before the createscreen...

Strange that works again:-

Code (glbasic) Select Expand

cscreen=GENSPRITE()
//SHOWSCREEN
CLEARSCREEN 0 //Make sure all is blanked out otherwise createscreen may copy from background and use it as transparent layer
CREATESCREEN 0,cscreen,targetx/2,(targety/2)/3 //Make it a small window so is faster on higher resolution screensBut if you unrem the showscreen it doesn't blank out the createscreen. Pretty sure it worked with showscreen unremmed and clearscreen remmed though... Yep just tested and that is true too. Just doesn't work with showscreen and clearscreen before the createscreen. Strange eh? Plus rem showscreen and clearscreen and it doesn't work there either... Not very logical..

Careful though as that one is actually quite a good feature if we can control it. Make it like the last version and have it completely black as default, but add a new optional parameter to createscreen to make it use the backbuffer as somesort of transparent layer then that would be cool. As I said it has benefits that I can't think how to program easily to allow a quick FPS. I mean my routine is similar to your scribble routine (sort of) and works well speed wise on any resolution it seems. But maybe I will change to have a different background for the paint routine. Then when it saves the usescreen sprite it only saves what you have drawn, not the background (which is what the error is doing). Nice...

Cheers

[Crivens]

Ignore me. This has weird results. The code below works every time, but when it goes back into it for a second time it doesn't clear at all, even though I use a loadsprite "",cscreen at the end of the routine.

Best bet is just to get it back to how it was yesterday before 10.203.

Cheers

[Sixth Sense]

It's taught me how much I use the down key when I'm editing!

Copying EditorE.exe  from the backup zip file and overwriting the one in the install folder has given me a temporary fix for the time being.

[Crivens]

Ah ang on, the createscreen is even more interesting. I'm now on my laptop using Win7 and GLB 10.191.

Strangely now the above code (showscreen remmed out and clearscreen being used before createscreen) causes the same bug as 10.203 without the clearscreen or showscreen. ie. the usescreen is not blank but has the background of the backbuffer. And cannot be removed. It's like it's the default "black" background. Do a drawrect on the screen and it blanks out everything else that was drawn to the usescreen since the createscreen. Just not the default "black" background which remember is what was on the screen originally.

If I remove the clearscreen (so is just createscreen) on 10.191 then it works as it did yesterday! ie. black background to the createscreen. But then if I go back to the routine in the same session it will produce the same bug as above! WTF?

Seriously strange stuff here. Surely a createscreen should be like a brand new screen with just black as the backdrop? Fair enough if have an option for a background graphic that stays there even if the screen is blanked (and won't exist if save the sprite as the current bug does currently), but the default action needs to be 100%.

Cheers

[Crivens]

GLB 10.205 fixes the cursor key problem and my createscreen problem is back to how it was yesterday.

So basically I use gensprite then createscreen (with screen 0) to get a black smaller than screen sized rectange, and draw to that. When the routine is finished I loadsprite "" with the createscreen sprite to remove it from memory. When the routine is called in the future (on the same session) then I get the bug where the backbuffer is copied to the createscreen (either that or all the pixels are transparent) and the area I draw to is not black (is the same as the actual graphics underneath it) but when I savesprite the screen it only saves the drawn graphics since the createscreen (ie. like it's supposed to be with black background).

Cheers

[MrTAToad]

Might be worth using CREATESCREEN with a size of 0,0 as well as deleting the associated sprite.

[Crivens]

I tried that at the end of the routine and with 1,1 but both don't make any difference.

Here is the code at the end of the function:-

Code (glbasic) Select Expand

SAVESPRITE docdir$+"/high"+painthigh+".png",cscreen
CREATESCREEN 0,cscreen,0,0 //Make sure resizes so clears out created screen
LOADSPRITE "",cscreen //Clear out memory
USESCREEN -1

Cheers

[Kitty Hello]

Post a standalone example please?

[Crivens]

Easier said than done really. Will try and get something together tomorrow.

For a summary though in a sub-file I have a function where I use screen 0 with createscreen and create a screen the width of the device and a third the height. Obviously I then usescreen to draw everything to it. With 10.205 this nicely blacks out what is underneath (a 3DES created backdrop) when I stretchsprite the created screen onto the proper screen. At the end of the routine I loadsprite "" with the createscreen sprite, and as mentioned above use createscreen again (although makes no difference if I do this or not) with screen 0 at a size of 0,0 to see if that resets screen 0.

Next time I enter the routine (in the same run) it obviously uses createscreen again on screen 0, but this time it does not black out what is underneath. It is basically transparent. Although everything else is fine with what is drawn to screen 0 using usescreen and it even savesprites perfectly fine (including the transparent bits being black as they should be in this case).

Cheers