Undependeable Gadget Handle

[Lord]

As I already tried to explain in this thread
http://www.purebasic.fr/english/viewtop ... =4&t=55925
there are still circumstances that you can't trust
a returned handle.

In the above thread, I showed, that a handle
returned by CanvasGadget() can be invalid, even
if there was no error or warning raised.
freak tried to overcome this failure by arbitrarily
limit the size of CanvasGadget to 16000x16000.
Fred wrote, that there is a 2 GB limit. But you
can't use the Gadget within this 2GB limit.

That was one story.

Now, I discovered, that a returned handle for
ScrollAreaGadget also can't be trusted.
If you create a ScrollAreaGadget for example
32768x200 you get a handle, the Gadget is created,
but you can't use the whole size.
Please notice, that you can use a CanvasGadget
larger than 16000 in one direction.

Code: Select all

Procedure SAGx()
  SetWindowTitle(1, Str(GetGadgetAttribute(1, #PB_ScrollArea_X)))
EndProcedure


OpenWindow(1, 10, 10, 600, 600, "")

hScrollAreaGadget.i=ScrollAreaGadget(1, 0, 378, 600, 222, 64000, 200)
; no error or warning is raised here


BindGadgetEvent(1, @SAGx()); just display x-pos of ScrollAreaGadget in WindowTitle

DisableDebugger
  hCanvasGadget.i=CanvasGadget(2, 0,0,64000, 200)
; CanvasSize is way below 2GB-limit, but because of the 16000x16000 limit arbitrarily
; intruduced in PB 5.20 we have to disable debugger in order to get what we want  
EnableDebugger

CloseGadgetList()

Debug hScrollAreaGadget; shows valid handle
Debug hCanvasGadget; shows valid handle

CreateImage(1, 200, 200); Create something to display

StartDrawing(ImageOutput(1))
  LineXY(0 ,0, 199, 199, $0000FF)
  LineXY(199, 0, 0, 199, $0000FF)
StopDrawing()

;Display Image in different positions 
StartDrawing(CanvasOutput(2))
  DrawImage(ImageID(1), 0, 0)
  
;
  DrawImage(ImageID(1), 32000-200, 0) ; visible
  DrawImage(ImageID(1), 32768-200, 0) ; visible
  DrawImage(ImageID(1), 64000-200, 0) ; NOT visible
;

StopDrawing()

Repeat
  Event=WaitWindowEvent()
Until Event=#PB_Event_CloseWindow

So, again, you can't trust a returned handle.
I wonder if there are more of these unreliable handles exists.

[IdeasVacuum]

I get the impression that you are venturing into the unknown Lord. A huge canvas size might be taken for granted at sometime in the future, but at the moment I think you are right on the edge of what the OS can do - so it's fair to expect the unexpected in these circumstances. In a few years time we will all have PCs equipped with at least 32GB RAM and 64GB will be common place. At that time it may be the case that the very large screens are popular too Microsoft Perceptive Pixel
Today, you are ahead of your time (a Time Lord for those that know). If you really need to go for it, then you probably need to either use a lower-level language and define everything yourself, or move sideways and work with the Perceptive Pixel API.

[Olby]

32768x200

Facepalm! That's nearly 23x times the width of my screen. On a serious side, have you considered using DX or OpenGL to create hardware buffered windowed screen? I bet that most gadgets will fail at these monstrous dimensions so it's not a sustainable way to do it. Also I'm pretty sure that most of these issues are due to Windows returning an invalid handle, as I had such situations before. Test it on Linux/OSX to see if it's a cross-platform issue.

[Lord]

...That's nearly 23x times the width of my screen. On a serious side, have you considered using DX or OpenGL to create hardware buffered windowed screen? I bet that most gadgets will fail at these monstrous dimensions so it's not a sustainable way to do it. Also I'm pretty sure that most of these issues are due to Windows returning an invalid handle, as I had such situations before. Test it on Linux/OSX to see if it's a cross-platform issue.

You missed the point.
Do you always know when you cross the border reliable/unreliable handle ?
No, you can't. PureBasic lets you think, you are on the safe side.
But you aren't. Don't trust a returned handle.
If windows returns an invalid handle, why returns PureBasic a valid one?
Did you see, that PB generates the Gadgets without any lament?
ScrollAreaGadget just cuts of at 32768. PB says everthing is OK, you got
a handle. And CanvasGadget works also, if you have enough memory and
respect this 2GB limit without any problems. No need for a 16000 pixel limit.
It is not the task of PureBasic to introduce artifical limits and hinder the
user to use the capabilities of his machine.
As I'm not using Linux, cross-platform is not an issue for me.

[Fred]

PB says it's OK because Windows says it's OK, and it returns a window cut to 32768 instead of failing. You can ask Microsoft about it. Added debugger check for all gadgets to ensure the size is less than 16000x16000 so it will get catched.

[Lord]

...Added debugger check for all gadgets to ensure the size is less than 16000x16000 so it will get catched.

You are still going to cripple PureBasic?
My code shows you, that a ScrollAreaGadget does work with more than
16000 Pixel in with. Also a CanvasGadget is working.
PureBasic should detect when those limits are reached and allow the
use of a gadget within these limits. Do not introduce artifical limits.

[IdeasVacuum]

Lord, 16000x16000 is huge, that is not crippling PB. The PB compiler cannot check when greater limits would be reached, so essentially you are asking Fred to add new functionality to PB so that your app can perform checks at run time. Even that is more complex than it sounds (especially cross-platform) and you are probably the only PB User who is interested in this capability....... so, it surely has to be a Feature Request.

That said, many Devs here have given excellent suggestions on how to move forward with your project.

[Lord]

Lord, 16000x16000 is huge, that is not crippling PB.
...

If you can use a 32000x200 Canvasgadget in a 32000x200 ScrollAreaGadget
and Fred is going to set a limit at 16000 you can use only half the possible
size.
That is not crippling?
And why is Fred intruducing a limit for ScrollAreGadget at 16000 even though
Windows allows 32000 whithout any problem?
Adding a debugger check is not helpfull in any way at runtime.
But yes, that's an easy way. Let's be lazy.

[PB]

> why is Fred intruducing a limit for ScrollAreGadget at 16000 even though
> Windows allows 32000 whithout any problem?

But what do Linux and MacOS allow? If they can't use ScrollAreaGadgets
over 16000 pixels, then that's why the Windows version will stop at that.
The code must be able to work on all 3 operating systems the same way.

[Lord]

> why is Fred intruducing a limit for ScrollAreGadget at 16000 even though
> Windows allows 32000 whithout any problem?

But what do Linux and MacOS allow? If they can't use ScrollAreaGadgets
over 16000 pixels, then that's why the Windows version will stop at that.
The code must be able to work on all 3 operating systems the same way.

I just tried with Ubuntu 12.04.1 in a VM.
A ScrollAreaGadget 65536x200: It works like a charme.
I tried also 128000x200: Still works!
A CanvasGadget 32767x200 in this ScrollAreaGadget: works perfect also.
32767 seems to the limit here.
You see: there is no reason for a arbitrary decision for a 16K-limit. 32k will do.

I don't know wether for a Mac it works or not. I don't have access to such machine.
So you have the (...) excuse "Mac won't allow this".

[IdeasVacuum]

Is the sheer pixel size the only consideration though? I think not. Unless your app is going to be the only one on the computer and can thus access all resources/CPU/GPU/RAM, which have been specified to suit the app's requirements.....

Perhaps Fred can find a better max size. If he can, I have no doubt that he will. I trust his judgement and I think you should to - you are using PB because it's so good, right? I know that's why I use it.

[Fred]

I tried on OS X and it works for 32k as well, so I raised to limit to that.

[Lord]

Why is this topic closed?
It's referenced in my first posting here.
Whithout that closed thread, my postings
are crippeled also and other users can't
understand the whole issue.

[Fred]

It's not closed, it's moved in an hidden bug fixed forum.

[luis]

It's not closed, it's moved in an hidden bug fixed forum.

About this, could be possible to make accessible through direct link those posts too ?

I understand stopping them from being found through a search, and displayed in the normal consultation of the forum.
That's ok.

But sometime even the bug reports contain useful information, so it would be nice if knowing the link you could see it.
One case is when you bookmarked it because there was something interesting in the thread.
Another one when a post it's linked in another post.

They could be read only obviously. Having a "DONE" in the title would make clear what they are.

Don't know if it's possible, just a suggestion.