Virtual Gadgets

[nospam]

I'd like to have the ability to create a virtual gadget as an object and work on the gadget's attributes in code then blat the gadget onto the screen rather than having to do all the work on screen where the user can see the gadget being changed. I'd also like to be able to copy a gadget off the screen and virtualise it to work on it in code. These would be valuable features when screen layout needs to change, for example.

Assume an application with two similar but different windows. Rather than showing a new window, an existing gadget can be replaced by the virtual gadget in a single step.

The advantage is that, say, a TreeGadget can be prefilled with data before being put on the screen. That is, the gadget is filled and ready to be seen by the user before the user actually sees it.

Virtualising gadgets will allow a smoke and mirrors trick I use in other languages to make an application appear far faster than it is. In the scenario I described, the new gadget appears on the screen already pre-filled so the user doesn't see the gadget actually filling. I also use same the feature to take advantage of the of some gadgets' abilities without having to create a hidden screen. For example, let's say a TreeGadget can perform sorts on its contents. I might then build a virtual TreeGadget to use its sorting ability then extract the sorted information and use it for some undetermined purpose. This way I use a feature of the gadget to do some work that would otherwise require me to write code.

Example code:

Code: Select all

      NewGadget MyGadget = TreeGadget(#PB_Any, 10, 10, 160, 160) ; Create a gadget in memory
      MyGadgetID = GadgetID(MyGadget)

      For a = 0 To 10
        AddGadgetItem(MyGadgetID, -1, "Normal Item "+Str(a), 0, 0)
        AddGadgetItem(MyGadgetID, -1, "Node "+Str(a), 0, 0)
        AddGadgetItem(MyGadgetID, -1, "Sub-Item 1", 0, 1)
        AddGadgetItem(MyGadgetID, -1, "Sub-Item 2", 0, 1)
        AddGadgetItem(MyGadgetID, -1, "Sub-Item 3", 0, 1)
        AddGadgetItem(MyGadgetID, -1, "Sub-Item 4", 0, 1)
        AddGadgetItem(MyGadgetID, -1, "File "+Str(a), 0, 0)
      Next
      
      ReplaceGadget(MyWindow, SomeGadgetID, MyGadget) ; Replace an existing gadget, any gadget, with the virtual gadget
      AddGadget(MyWindow, MyGadget) ; Put the virtual gadget on the window with coordinates 10, 10, 160, 160
      AddGadget(MyContainerGadget, MyGadget) ; Attach the virtual gadget to an existing container
      MyClonedGadget = GetGadget(MyGadgetID) ; Clone a gadget that's on the window and virtualise it
      ; Do some stuff to the cloned gadget
      ...
      ...
      ; Put the cloned and now modified gadget back on the screen
      ReplaceGadget(MyWindow, MyGadgetID, MyClonedGadget) 
      ...
      ...

MyGadget & MyClonedGadget could either become the very same gadget or MyGadget is destroyed.

[spikey]

HideGadget()? http://www.purearea.net/pb/english/manu ... adget.html

[nospam]

HideGadget()?

No.

[srod]

At the Windows API level you can easily disable screen updates for a gadget and then re-enable it when you are done. For cross-platform you can simply create the gadget off screen and then use ResizeGadget() when you are done populating it etc. to move it into vision.

Never encountered 'virtual gadgets' in any other language.

[skywalk]

HideGadget()?

No.

Curious? Why does this not work for you?

Code: Select all

  HideGadget(someGadgetID,1)
  ;...do stuff with your hidden Gadget...
  HideGadget(someGadgetID,0)

I build entire gui's -- windows and menu's and images while hidden.
Using gadgets for sorting is not always efficient or flexible. Escpecially if your data is numeric or complex?
Better to have your data in arrays and use gadgets for display.

[nospam]

At the Windows API level you can easily disable screen updates

Maybe so, but there are two issues. Firstly, I run Linux and would like to see a cross-platform implementation of my idea. Secondly, I did say I don't want to hide or disbale gadgets because I want to use them off-screen.

For cross-platform you can simply create the gadget off screen and then use ResizeGadget() when you are done populating it etc. to move it into vision.

Well there you go, see. A gadget created off-screen is a virtual gadget. So how do you create a gadget off-screen?

Never encountered 'virtual gadgets' in any other language.

They are supported by at least Mono on Linux and Visual Studio on Windows in C#, Basic, J# and F#.

[nospam]

Using gadgets for sorting is not always efficient or flexible."

That's an all-encompassing statement and is therefore false by definition. I have used tree controls on Window$ in the past to very quickly and efficiently sort very complex structures.

Better to have your data in arrays and use gadgets for display.

Rubbish. If your statement was true, which it isn't, then there'd be no need for things like linked lists.

Edit:

HideGadget()?

No.

Curious? Why does this not work for you?

Because if you had actually read what I wrote you would have immediately noted that it doesn't meet the requirements.

[skywalk]

Using gadgets for sorting is not always efficient or flexible."

That's an all-encompassing statement and is therefore false by definition. I have used tree controls on Window$ in the past to very quickly and efficiently sort very complex structures.

Better to have your data in arrays and use gadgets for display.

Rubbish. If your statement was true, which it isn't, then there'd be no need for things like linked lists.

Yes, linked lists and/or arrays are faster than gadgets for sorting lists.

HideGadget()?

No.

Curious? Why does this not work for you?

Because if you had actually read what I wrote you would have immediately noted that it doesn't meet the requirements.

I did read, but you apparently don't care to elaborate? And I rarely grasp things "immediately".

[nospam]

I did read, but you apparently don't care to elaborate? And I rarely grasp things "immediately".

lol - I did enough elaboration in the OP. The idea is to be able to work on gadgets, no matter what that work is, in memory rather than on screen. For example, virtual gadgets could be used to build a container with a number of gadgets already setup and filled, ready to display. Instead of opening a new window to display different information you can simply replace an existing container. You might do that, like I said, for a smoke and mirrors trick, or to save time building multiple windows, etc. etc.

I think the problem you're having is one of a lack of imagination

[Danilo]

Never encountered 'virtual gadgets' in any other language.

They are supported by at least Mono on Linux and Visual Studio on Windows in C#, Basic, J# and F#.

Would you mind to please provide a link to us with some more information about this topic in VS.NET/Mono?
Maybe that would help to understand what it exactly is, that you want/mean and why it could be useful for many of us.
If I think about and search for "virtual control" in VS/MSDN, nothing comes to mind and no useful search results are shown.
Naming the real technologie/thing could help to clear things up. ATM only something like a data provider that feeds the Gadget
comes to mind, but with your code example in posting 1 I can't really see an advantage/usefulness for PureBasic and PureBasic users.

Something like #WM_SETREDRAW on windows would indeed be useful cross-platform for allowing fast gadget content manipulation
without re-painting/updating the display on every change. Managing and manipulating the content/data of gadgets off-screen would
be done with Linked Lists, Maps and Arrays, but you would change the gadget content yourself between two EnableGadgetRedraw() calls,
so it is much faster.

Thanks in advance for some more information and explanation!

[skywalk]

Yes yes. You have repeated yourself again without elaboration?
What can you not do now with the existing gadgets "behind the scenes" using #PB_Any?
Are you going to ask for "virtual menus" next?
Imagination is not lacking.
It's understanding a problem given no failing example.

[nospam]

Would you mind to please provide a link to us with some more information about this topic in VS.NET/Mono?
Maybe that would help to understand what it exactly is

It is simply the ablity to assign a gadget to a variable; a reference.

http://msdn.microsoft.com/en-us/library/77s47661.aspx
http://msdn.microsoft.com/en-us/library/7ee5a7s1.aspx

[nospam]

Are you going to ask for "virtual menus" next?

I already did. Menus are gadgets, are they not?

[srod]

For cross-platform you can simply create the gadget off screen and then use ResizeGadget() when you are done populating it etc. to move it into vision.

Well there you go, see. A gadget created off-screen is a virtual gadget. So how do you create a gadget off-screen?

Code: Select all

ButtonGadget(1, -1000, -1000, 80, 20, "CLICK!")

I think that would be off-screen in most apps! I wouldn't class this as a virtual control though; as far as Windows is concerned this is as real as any other control with real memory allocated to it and so on. The only difference being that the paint handler would not be invoked whilst no part of the control was visible.

I wouldn't even class the .Net classes as virtual controls either. As soon as you instantiate such a class then I would say that there is every likelihood that the relevant control is created and simply dumped off-screen. Otherwise the class itself may find itself having to duplicate all the data (in the case of a treeview for example) you then proceed to add to the control. Just doesn't add up to me.

[nospam]

For cross-platform you can simply create the gadget off screen and then use ResizeGadget() when you are done populating it etc. to move it into vision.

Well there you go, see. A gadget created off-screen is a virtual gadget. So how do you create a gadget off-screen?

Code: Select all

ButtonGadget(1, -1000, -1000, 80, 20, "CLICK!")

I think that would be off-screen in most apps!

lol - yes, it would be 'off screen', but it would still be on a form.

I wouldn't even class the .Net classes as virtual controls either. As soon as you instantiate such a class then I would say that there is every likelihood that the relevant control is created and simply dumped off-screen.

I'd lol again but I'm sure you're serious.