Virtual Gadgets

[Fred]

@nospam: please change your global tone when contributing to this forum. People here spend time to try to help you, if your only way to post is being sarcastic and/or harsh, you can go somewhere else.

[nospam]

@nospam: please change your global tone when contributing to this forum. People here spend time to try to help you, if your only way to post is being sarcastic and/or harsh, you can go somewhere else.

Point taken.

[srod]

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.

Yep, definitely. Common sense for any experienced developer really I would say.

Take a Win treeview for example. You add 10000 rows then the control itself will manage the memory (unless you specify otherwise) required for these rows; including the underlying string data. It simply would not make sense for a .NET wrapper class to store all of this information separately prior to creating the control via CreateWindowEx_() as the duplication would be quite horrendous and the business of transferring the data would, in speed terms, undo the benefits of having the control off screen anyhow. Sure I am not 100% on this because I do not possess the .NET source code, but I would say that it is a reasonable 'guess'.

In terms of being off-screen, yes the control would still reside within a form, but that is immaterial. The fact is that the control's paint event will not fire (or will fire with an empty update region) and thus populating such a control will, depending on how much data is being added, be significantly faster than having the control fully visible from the outset.

Anyhow, I think I should probably refrain from responding to any more of your posts given your very negative attitude to those trying to help. Got better things to do really.

[Danilo]

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

Thanks, now I understand what you meant. You create "off-screen" controls like:

Code: Select all

var btn = new Button();
var lb1 = new ListBox();

You can work with the controls, even if they are not assigned to a window.
Later on you add those controls to a window/layout manager.

Moving a control to another window/layout manager is simply done by removing it from current parent control
and add it to another window/layout manager (not possible with plain PB, something like SetParent_() with WinAPI).

Code: Select all

using System;

namespace WpfApplication
{
    class Window : System.Windows.Window
    {
        private System.Windows.Controls.Canvas grid;

        public Window(int x, int y, int width, int height, string title)
        {
            Left = x;
            Top = y;
            Width = width;
            Height = height;
            Title = title;

            grid = new System.Windows.Controls.Canvas();
            Content = grid;
        }
        public void Add(System.Windows.UIElement e)
        {
            grid.Children.Add(e);
        }
        public void Remove(System.Windows.UIElement e)
        {
            grid.Children.Remove(e);
        }
    }

    class Button : System.Windows.Controls.Button
    {
        public Button(int x, int y, int width, int height, string title)
        {
            Content = title;
            Width = width;
            Height = height;
            System.Windows.Controls.Canvas.SetLeft(this, x);
            System.Windows.Controls.Canvas.SetTop(this, y);
        }
    }

    class ListBox : System.Windows.Controls.ListBox
    {
        public ListBox(int x, int y, int width, int height)
        {
            Width = width;
            Height = height;
            System.Windows.Controls.Canvas.SetLeft(this, x);
            System.Windows.Controls.Canvas.SetTop(this, y);
        }
    }

    class Program
    {
        [STAThread]
        public static void Main(string[] args)
        {
            var w1 = new Window(10, 10, 800, 600, "Window 1");
            var w2 = new Window(400, 100, 800, 600, "Window 2");

            //
            // create controls, they are not bound to a window ("off-screen")
            //
            var btn = new Button(10, 10, 100, 25, "Exit");
            var btn2 = new Button(10, 50, 100, 25, "Button 2");

            var btn3 = new Button(10, 10, 100, 25, "Button 3");
            var btn4 = new Button(10, 50, 100, 25, "Button 4");

            var lb1 = new ListBox(120,10,200,200);
            for(var i=1;i<100;i++)
                lb1.Items.Add("Line " + i.ToString());

            btn.Click += Shutdown;
            w1.Closed += Shutdown;

            //
            // add the controls to a window/layout manager
            //
            w1.Add(btn);
            w1.Add(btn2);

            w2.Add(btn3);
            w2.Add(btn4);
            w2.Add(lb1);

            //
            // remove lb1 from w2, then add lb1 to w1
            //
            w2.Remove(lb1);
            w1.Add(lb1);


            w1.Show();
            w2.Show();

            DoEvents();
        }

        static void DoEvents()
        {
            System.Windows.Threading.Dispatcher.Run();
        }

        static void Shutdown(object o, System.Windows.RoutedEventArgs e)
        {
            System.Windows.Threading.Dispatcher.CurrentDispatcher.InvokeShutdown();
        }

        static void Shutdown(object o, System.EventArgs e)
        {
            System.Windows.Threading.Dispatcher.CurrentDispatcher.InvokeShutdown();
        }
    }
}

If PB had something similar to SetParent_() on Windows, for moving gadgets to another window/container at runtime,
most of your wishes could be emulated (combination of HideWindow/SetGadgetParent). CopyGadget/CloneGadget isn't that easy
at runtime. Determine gadget type, create new gadget of same type and copy all attributes/items from old to new gadget.

[nospam]

Yep, definitely. Common sense for any experienced developer really I would say.

Take a Win treeview for example. You add 10000 rows then the control itself will manage the memory (unless you specify otherwise) required for these rows; including the underlying string data. It simply would not make sense for a .NET wrapper class to store all of this information separately prior to creating the control via CreateWindowEx_() as the duplication would be quite horrendous and the business of transferring the data would, in speed terms, undo the benefits of having the control off screen anyhow. Sure I am not 100% on this because I do not possess the .NET source code, but I would say that it is a reasonable 'guess'.

In terms of being off-screen, yes the control would still reside within a form, but that is immaterial. The fact is that the control's paint event will not fire (or will fire with an empty update region) and thus populating such a control will, depending on how much data is being added, be significantly faster than having the control fully visible from the outset.

Very good. You got it.

Anyhow, I think I should probably refrain from responding to any more of your posts given your very negative attitude to those trying to help. Got better things to do really.

I will make an apology.

[Danilo]

Take a Win treeview for example. You add 10000 rows then the control itself will manage the memory (unless you specify otherwise) required for these rows; including the underlying string data. It simply would not make sense for a .NET wrapper class to store all of this information separately prior to creating the control via CreateWindowEx_() as the duplication would be quite horrendous and the business of transferring the data would, in speed terms, undo the benefits of having the control off screen anyhow. Sure I am not 100% on this because I do not possess the .NET source code, but I would say that it is a reasonable 'guess'.

In terms of being off-screen, yes the control would still reside within a form, but that is immaterial. The fact is that the control's paint event will not fire (or will fire with an empty update region) and thus populating such a control will, depending on how much data is being added, be significantly faster than having the control fully visible from the outset.

I think nospam is right here. You create controls (objects of classes) and the methods/functions to work with the data in it are independent
from the display part. It is just data in memory and functions that work on that data - without being bound to a window or container.
The real visual control is created when you add it to a window/container and is destroyed if you remove it, but the data still is in memory,
what nospam called "off-screen". I didn't think about this, for me it is just the way the .NET controls/classes work.
The .NET controls are not always just wrappers to WinAPI. Old WinForms framework was an WinAPI wrapper, but newer WPF components
don't use the original WinAPI controls under the hood - they are new, hardware accelerated painted controls that rely on milcore.dll (DirectX GUI functions).
Microsoft software like Expression, Visual Studio and Office actually use this newer WPF framework.

You can play with it and compile the above C# source on Windows if you have .NET framework 4 installed. No VisualStudio required.
Use the following .BAT to compile (change paths to your .NET framework version):

Code: Select all

@echo off
@SET COMPILE="c:\windows\microsoft.net\framework\v4.0.30319\csc.exe"
@SET NET_DLLS="c:\windows\microsoft.net\framework\v4.0.30319"
@SET WPF_DLLS="c:\windows\microsoft.net\framework\v4.0.30319\WPF"

@REM milcore.dll                DirectX for WPF, not public
@REM 
@REM windowsbase.dll            Base logic, property system
@REM presentationcore.dll       Layout, Data Binding, ...
@REM presentationframework.dll  Controls, Documents, ...
@REM 
@REM System.Xaml.dll            XAML, used by WPF DLLs
@REM 
@REM WindowsFormsIntegration.dll Namespace System.Windows.Forms.Integration
@REM                             for Interoperability with Windows Forms
@REM
@SET REFERENCES=/r:windowsbase.dll /r:presentationcore.dll /r:presentationframework.dll /r:System.Xaml.dll


@%COMPILE% /nologo /checked+ /nowin32manifest /optimize+ /out:WpfWindow.exe /t:winexe /lib:%WPF_DLLS%,%NET_DLLS% %REFERENCES% *.cs
@pause

[srod]

Must admit that I have little experience with .NET (and none with WPF) and, with milcore.dll in mind, what you say makes sense.

However, doesn't really change the fact that the closest NoSpam will get to 'virtual gadgets' with PB is to use an off-screen gadget. Unless he wishes to create his own wrapper classes that is... and a Direct3D rendering engine!

[Danilo]

However, doesn't really change the fact that the closest NoSpam will get to 'virtual gadgets' with PB is to use an off-screen gadget.

Yes. With a new PureBasic command to move Gadgets to different windows/container (cross-platform, like SetParent_() on Windows),
I see new cross-platform possibilities like floating dock windows. A container docked to the main window gets removed there and is added
to a newly opened "floating tool window" at runtime and maybe docked again later to the main window.
Also, automatic layout managers that control the size and position of child gadgets, could be changed at runtime by creating a new layout manager gadget
and move all child windows from the old layout manager to the new layout gadget at runtime.

[nospam]

However, doesn't really change the fact that the closest NoSpam will get to 'virtual gadgets' with PB is to use an off-screen gadget. Unless he wishes to create his own wrapper classes that is... and a Direct3D rendering engine!

No big deal, really. It was just an idea; this is "Feature requests and Wishlists" afterall.

and a Direct3D rendering engine!

Yes, on Linux, without having to install wine no less

[srod]

Stick to off-screen gadgets!