Getting the ball rolling. Which VB6 projects are you working on?

Quote:

---

Originally Posted by fafalone

No but the RichEdit control doesn't require the ribbon. I just used the ribbon project out of convenience since it had a RichEdit with so many options already set up. All the RichEdit control really needs is a few lines to call LoadLibrary and CreateWindowEx; you don't need additional controls at all let alone the fancy ribbon ones. I don't think the XAML version includes a whole text editor UI for setting fonts/alignment/etc either, just some wrappers to simplify the API calls a bit.

I'm going to play around a little with windowless richedit... just see if I can get the bare minimum functionality working then go from there.

---

Looking forward to your new work. If Bill Gates is still the chairman. You will be the mvp best expert.

Quote:

---

Originally Posted by fafalone

No but the RichEdit control doesn't require the ribbon. I just used the ribbon project out of convenience since it had a RichEdit with so many options already set up. All the RichEdit control really needs is a few lines to call LoadLibrary and CreateWindowEx; you don't need additional controls at all let alone the fancy ribbon ones. I don't think the XAML version includes a whole text editor UI for setting fonts/alignment/etc either, just some wrappers to simplify the API calls a bit.

I'm going to play around a little with windowless richedit... just see if I can get the bare minimum functionality working then go from there.

---

Just out of curiosity I've modified Franky's "XamlHosting2" example to include a RichEditBox. Apparently all you need as barebones is:

Code:

---

            Dim xaml As String
            xaml = "<Grid xmlns='http://schemas.microsoft.com/winfx/2006/xaml/presentation' " & _
                  "xmlns:x='http://schemas.microsoft.com/winfx/2006/xaml' Background='White'>" & _
                        "<StackPanel x:Name='LayoutRoot' Margin='10'>" & _
                            "<Button x:Name='btn1' Content='Button 1' Margin='5' Width='150' HorizontalAlignment='Left' Background='#F0F0F0' Foreground='Green'/>" & _
                            "<Button x:Name='btn2' Content='Button 2' Margin='5' Width='150' HorizontalAlignment='Left' Background='#F0F0F0' Foreground='Blue'/>" & _
                            "<Button x:Name='btn3' Content='Button 3' Margin='5' Width='150' HorizontalAlignment='Left' Background='#F0F0F0' Foreground='Red'/>" & _
                            "<RichEditBox Width='300' Height='200'/>" & _
                        "</StackPanel>" & _
                    "</Grid>"

---

That's it, no "LoadLibrary" or "CreateWindowEx" required, in fact the RichEditBox comes fully featured with Spellchecking and Color Emojis already enabled and a modern context menu to boot. Of course there are a lot more properties, methods and events to implement if you want to make something nice out of it.

Attachment 193896

Sorry for being lazy and not researching it myself, but does the XAMLIsland RTB support the EM_* messages, especially EM_FORMATRANGE? Or is it a completely different beast?

As far as I've seen there are no "EM_*" messages at all. The paradigm has been abstracted entirely to an object oriented model but all the old-school message-based functionality is still there encapsulated in ready-to-use interfaces such as "ITextSelection" or "ITextParagraphFormat" (and many others I'm sure) so it would take a while to absorb this new information but it should be well worth it in the end especially since all these interfaces could be easily written in tB.

Quote:

---

Originally Posted by VanGoghGaming

As far as I've seen there are no "EM_*" messages at all. The paradigm has been abstracted entirely to an object oriented model but all the old-school message-based functionality is still there encapsulated in ready-to-use interfaces such as "ITextSelection" or "ITextParagraphFormat" (and many others I'm sure) so it would take a while to absorb this new information but it should be well worth it in the end especially since all these interfaces could be easily written in tB.

---

Thanks for the info. Sounds like it might use the same TOM interfaces as the existing RTB? Not sure because TOM has ITextPara and ITextPara2 but not ITextParagraphFormat, so maybe they use different object models. The thing I would be most interested in knowing is if it support something similar to EM_FORMATRANGE to measure the height of a subset of the RTF document based on a character range. I use that extensively to simulate linked text areas within a larger document to support overflowing RTF text from one page to another within different regions of the pages.

For example, on page 1 I have a "virtual" box at

Code:

---

X1: 100
Y1: 100
X2: 500
Y2: 5000

---

On page 2 I have a "virtual" box at

Code:

---

X1: 250
Y1: 500
X2: 650
Y2: 5000

---

When the user types, I calculate the text height/caret position to see if everything should fit/display on page 1, and if not I bump to page 2 and adjust the top line of the RTB to the first line of page 2 - similar to a viewport for a large image. I'd be interested to know if this kind of behaviour would be possible with the XAML Island RTB (or even the Office D2D RTB)? Anyway, I'll have to do some more research.

It has been my experience that these new WinRT interfaces include all the existing functionality and often times adding new features rather than removing existing ones. I haven't used "EM_FORMATRANGE" myself but it looks like the ITextRange.GetRect method might provide a similar functionality of measuring text. All you need is the patience for proper research.

On the bright side, I don't have any Office installed on this Win10 machine and the RichEditBox is working just fine!

Quote:

---

Originally Posted by VanGoghGaming

It has been my experience that these new WinRT interfaces include all the existing functionality and often times adding new features rather than removing existing ones. I haven't used "EM_FORMATRANGE" myself but it looks like the ITextRange.GetRect method might provide a similar functionality of measuring text. All you need is the patience for proper research.

---

Lovely, thanks for your time/help...I'll dig a bit deeper as time permits. My main reason to look for a new RTB has been to find one that is DPI agnostic in that line-breaks will always happen at the same character position regardless of host DPI. The D2D based RTBs apparently behave like this, but I haven't bothered to experiment with the Office RTB since most of my users have 64-bit Office installed. I've been waiting for tB's bit-mismatched host process to give it a serious try, but that is still a ways off according to the roadmap. But if I can get the XAML island RTB to work in 32-bit VB6, then I will start hammering away at it.

Yeah all these XAML controls are fully DPI aware, they scale automatically. The way I've been working with WinRT interfaces so far is write the definitions in a tB ActiveX DLL and reference that in VB6 so I can call the methods directly without any "DispCallFunc" tomfoolery! Of course, the DLL is only needed during development, doesn't need to be distributed. It's like a breath of fresh air to be sure! :D
Maybe you've seen my OCR example in the tB CodeBank forum to get a glimpse of what I'm talking about.

Quote:

---

Originally Posted by VanGoghGaming

Yeah all these XAML controls are fully DPI aware, they scale automatically. The way I've been working with WinRT interfaces so far is write the definitions in a tB ActiveX DLL and reference that in VB6 so I can call the methods directly without any "DispCallFunc" tomfoolery! Of course, the DLL is only needed during development, doesn't need to be distributed. It's like a breath of fresh air to be sure! :D
Maybe you've seen my OCR example in the tB CodeBank forum to get a glimpse of what I'm talking about.

---

Yes, I saw your OCR project, but I haven't had a chance to play with it yet...looks really good though! Unfortunately I still have a few high priority things over the next few weeks, but I look forward to digging into it and the XAML island stuff a bit soon.

Quote:

---

Originally Posted by VanGoghGaming

Just out of curiosity I've modified Franky's "XamlHosting2" example to include a RichEditBox. Apparently all you need as barebones is:

Code:

---

            Dim xaml As String
            xaml = "<Grid xmlns='http://schemas.microsoft.com/winfx/2006/xaml/presentation' " & _
                  "xmlns:x='http://schemas.microsoft.com/winfx/2006/xaml' Background='White'>" & _
                        "<StackPanel x:Name='LayoutRoot' Margin='10'>" & _
                            "<Button x:Name='btn1' Content='Button 1' Margin='5' Width='150' HorizontalAlignment='Left' Background='#F0F0F0' Foreground='Green'/>" & _
                            "<Button x:Name='btn2' Content='Button 2' Margin='5' Width='150' HorizontalAlignment='Left' Background='#F0F0F0' Foreground='Blue'/>" & _
                            "<Button x:Name='btn3' Content='Button 3' Margin='5' Width='150' HorizontalAlignment='Left' Background='#F0F0F0' Foreground='Red'/>" & _
                            "<RichEditBox Width='300' Height='200'/>" & _
                        "</StackPanel>" & _
                    "</Grid>"

---

That's it, no "LoadLibrary" or "CreateWindowEx" required, in fact the RichEditBox comes fully featured with Spellchecking and Color Emojis already enabled and a modern context menu to boot. Of course there are a lot more properties, methods and events to implement if you want to make something nice out of it.

Attachment 193896

---

I mean if you're excluding preexisting code it took fewer lines to upgrade my ribbon project :bigyello:

As I understand it, implementing event handlers for XAML was giving -Franky- some trouble; was that resolved?

The only trouble (if you can even call it that) is that with the classical VB6-DispCallFunc approach you need to create a lightweight object in a BAS module for the event delegate object. That is no longer the case with tB interfaces where you can just use "Implements" with the event interface and presto, Bob's yer uncle (or Bert seeing that we've highjacked his thread)! :D

Quote:

---

Originally Posted by VanGoghGaming

Is this "Windows App SDK" different than the XAML islands you were working on before? Do you have a download link for this project? Probably it would be easier to write the interface definitions in tB and then using them in VB6 rather than relying solely on DispCallFunc which is much more clunky and error-prone...

---

There is currently no download for my "Windows App SDK" test project. I have only been working on the project for 4 weeks, when I find the time, and I haven't gotten to the XAML controls (WinUI3) yet. I know that the interfaces are easier to write in TB than in VB6, where I use DispCallFunc. On the other hand, I already have so many VB6 classes for WinRT, XAML Islands, etc. that I can use them for the App SDK and don't have to write everything again for TB.

@VanGoghGaming You may understand my ventures in terms of WinRT, WinUI2 / WinUI3, App SDK, XAML Islands, etc. At some point you will not be able to avoid these technologies if you want to develop modern programs. The beginning is always difficult and at first glance looks very complicated and complex. The more you deal with the topic, the easier it becomes and then it doesn't look so complicated anymore.

Quote:

---

Originally Posted by fafalone

Copying two dlls is far less of an issue than the massive complexity of XAML islands.

---

The question would be, can this riched20.dll from Office be distributed with your own program if you don't have Office installed?

Preaching to the choir brotha, I'm already sold! It looks like fafalone might still be on the fence though! ;)

To be honest it does seem like you have an extensive .NET experience so it all comes more natural to you when translating these new technologies to VB6. For example I had no idea what were those "Grid" and "StackPanel" objects. I have now read more about them.

Quote:

---

Originally Posted by VanGoghGaming

To be honest it does seem like you have an extensive .NET experience so it all comes more natural to you when translating these new technologies to VB6. For example I had no idea what were those "Grid" and "StackPanel" objects. I have now read more about them.

---

I have a little experience with .NET and XAML. I'm more at home in VB in .NET. But for the XAML Islands I actually looked at the XAML in .NET to understand it better.

Quote:

---

Originally Posted by -Franky-

The question would be, can this riched20.dll from Office be distributed with your own program if you don't have Office installed?

---

It's an interesting question given that on Windows 11 the built in Notepad uses the new RichEditD2D pathway too so it might be included without Office. Probably technically no, but not something I'd be worried about unless it was commercial software from a large company. Certainly with them allowing MAS on GitHub I'm not worried about posting them with my demo apps there.

Quote:

---

Originally Posted by -Franky-

@VanGoghGaming You may understand my ventures in terms of WinRT, WinUI2 / WinUI3, App SDK, XAML Islands, etc. At some point you will not be able to avoid these technologies if you want to develop modern programs. The beginning is always difficult and at first glance looks very complicated and complex. The more you deal with the topic, the easier it becomes and then it doesn't look so complicated anymore.

---

Look how many technologies you just listed. Microsoft is creating and abandoning them so fast I'd bet on plain old basic Win32 API based UIs outlasting all of them.

Quote:

---

Originally Posted by fafalone

Look how many technologies you just listed. Microsoft is creating and abandoning them so fast I'd bet on plain old basic Win32 API based UIs outlasting all of them.

---

I agree with you completely. Technologies come and are discarded quite quickly at Microsoft. Of course, we still have the basis of the usual APIs and interfaces. But it seems to me that Microsoft is using the new technologies to focus on interfaces that contain the IInspectable interface. This is also the case with the interfaces of the App SDK. Of course, everything that has to do with the title bar could also be achieved with dwm.dll, themes.dll and Direct2D etc. The effort compared to the App SDK would be much higher. I'm also observing that more and more apps and the OS itself from Microsoft are using and using the new technologies. I assume that these technologies will not be abandoned so quickly.

Can we get this thread back on track chaps, please post images and progress on what you are up to at the mo', otherwise we are taking Xiaos's lead in prattling on about almost anything. A photo required please to make up for your rather long deviation.

Quote:

---

Originally Posted by -Franky-

My latest VBC project deals with the possibilities of the "Windows App SDK". As you can see in the picture, starting with Win11 you can even change the colors of the title bar and buttons. If you set AppWindowTitleBar.ExtendsContentIntoTitleBar = True, you can completely customize the title bar if you want. -> https://learn.microsoft.com/en-us/wi...elop/title-bar The dialog window was only created using the "Windows App SDK". As you can also see in the picture, quite a few classes and modules have already been put together for it. Let's see how far I get. :D

---

We can't see the content of your picture clearly. If you take a screenshot of the list of classes individually, it can be clearly displayed in vbForums. In other words, if the width of the image is not large, the image can be displayed clearly.

That's why I carefully adjust the width of my image every time to make it as clear as possible on vbForums.

Quote:

---

Originally Posted by VanGoghGaming

For example I had no idea what were those "Grid" and "StackPanel" objects. I have now read more about them.

---

These are standard objects in .Net's WPF used to control the layout of the UI. Anyone who used WPF would have been using Grids and StackPanels extensively.

Quote:

---

Originally Posted by jpbro

When the user types, I calculate the text height/caret position to see if everything should fit/display on page 1, and if not I bump to page 2 and adjust the top line of the RTB to the first line of page 2 - similar to a viewport for a large image. I'd be interested to know if this kind of behaviour would be possible with the XAML Island RTB (or even the Office D2D RTB)? Anyway, I'll have to do some more research.

---

Your approach is cool. I've even thought about doing the same thing, with a slightly different touch. But when it came to removing text from one line to the next page, using EM_FORMATRANGE I had a similar idea. But then I saw a method of drawing a line inside the RTB (to separate the pages), so I abandoned the style of doing it like you did.

Quote:

---

Originally Posted by jpbro

Thanks for the info. Sounds like it might use the same TOM interfaces as the existing RTB? Not sure because TOM has ITextPara and ITextPara2 but not ITextParagraphFormat, so maybe they use different object models. The thing I would be most interested in knowing is if it support something similar to EM_FORMATRANGE to measure the height of a subset of the RTF document based on a character range. I use that extensively to simulate linked text areas within a larger document to support overflowing RTF text from one page to another within different regions of the pages.

For example, on page 1 I have a "virtual" box at

Code:

---

X1: 100
Y1: 100
X2: 500
Y2: 5000

---

On page 2 I have a "virtual" box at

Code:

---

X1: 250
Y1: 500
X2: 650
Y2: 5000

---

When the user types, I calculate the text height/caret position to see if everything should fit/display on page 1, and if not I bump to page 2 and adjust the top line of the RTB to the first line of page 2 - similar to a viewport for a large image. I'd be interested to know if this kind of behaviour would be possible with the XAML Island RTB (or even the Office D2D RTB)? Anyway, I'll have to do some more research.

---

They should both support it. I know the Office control has been responding normally to all the EM messages and types. It's a regular windowed RichEdit just with a different renderer. the XAML one uses a windowless richedit, where supported features are highly implementation specific. since it won't have its own independent hwnd whatever one is hosting it may or may not forward old style messages to the underlying ITextServices object, though you might be able to get a pointer for that... probably wouldn't work well with the bolted on crap though.

Come on chaps, time to make your own thread.

I don't think it's reasonable to demand people not be asked questions and be allowed to answer regarding projects that they share they're working on.

Completely off topic? Of course. But we're talking about projects we're working on.

If this is a problem I'll refrain from sharing any future WIP in this thread, so it's not a risk for questions about it.

We just want to see pictures and see what you are working on, I recommend that you can open a more in-depth thread of your own that deals with your own particular issues and the responses to that. It is only when it goes too off track for post after post that I suggest opening another.

Totally unrelated: Geez I can't believe that its been almost 4 years since you started this thread!. Seems like just yesterday :).

Quote:

---

Originally Posted by fafalone

As I understand it, implementing event handlers for XAML was giving -Franky- some trouble; was that resolved?

---

I've been playing around with it some more, writing the various XAML interfaces in tB (there were quite a few even for the bare minimum required) and implementing proper events. It seems this XAML code is pretty flexible, you can even apply various gradients to all buttons as well as the StackPanel that's hosting them.

Here's an example with three buttons, each with a different ClickMode (Hover, Press and Release). Apparently in XAML you can choose a ClickMode for your buttons to choose when they fire their Click event.

Form1.frm

Code:

---

Option Explicit

Implements IRoutedEventHandler

Private Const SWP_SHOWWINDOW As Long = &H40, SWP_NOMOVE As Long = 2

Private Declare Function SetWindowPos Lib "user32" (ByVal hWnd As LongPtr, ByVal hWndInsertAfter As LongPtr, ByVal X As Long, ByVal Y As Long, ByVal cx As Long, ByVal cy As Long, ByVal uFlags As Long) As Long
                       
Private DesktopWindowXamlSource As IDesktopWindowXamlSource, Buttons(0 To 2) As IButtonBase, EventRegistrationTokens(0 To 2) As Currency

Private Sub Form_Load()
Dim XamlReaderStatics As IXamlReaderStatics, i As Long, XamlString As String
    Set DesktopWindowXamlSource = NewObject(eWindowsUIXamlHostingDesktopWindowXamlSource)
    With AsIDesktopWindowXamlSourceNative(DesktopWindowXamlSource)
        If .AttachToWindow(hWnd) = S_OK Then
            SetWindowPos .WindowHandle, 0, 0, 0, ScaleX(ScaleWidth, ScaleMode, vbPixels), ScaleY(ScaleHeight, ScaleMode, vbPixels), SWP_SHOWWINDOW Or SWP_NOMOVE
            XamlString = Clipboard.GetText
            Set XamlReaderStatics = NewObject(eWindowsUIXamlMarkupXamlReader, eIXamlReaderStatics)
            Set DesktopWindowXamlSource.Content = XamlReaderStatics.Load(NewStringRef(XamlString))
            With AsIFrameWorkElement(DesktopWindowXamlSource.Content)
                For i = LBound(Buttons) To UBound(Buttons)
                    With AsIButtonBase(.FindName(NewStringRef("Button" & i)))
                        .AddClick Me, EventRegistrationTokens(i)
                    End With
                Next i
            End With
        End If
    End With
End Sub

Private Function AsIButtonBase(Inspectable As IInspectable) As IButtonBase
    Set AsIButtonBase = Inspectable
End Function

Private Function AsIDesktopWindowXamlSourceNative(Inspectable As IInspectable) As IDesktopWindowXamlSourceNative
    Set AsIDesktopWindowXamlSourceNative = Inspectable
End Function

Private Function AsIFrameWorkElement(Inspectable As IInspectable) As IFrameworkElement
    Set AsIFrameWorkElement = Inspectable
End Function

Private Sub Form_Unload(Cancel As Integer)
    Dispose DesktopWindowXamlSource: Dispose WindowsXamlManager
End Sub

Private Sub IRoutedEventHandler_Invoke(ByVal Sender As IInspectable, ByVal Args As IRoutedEventArgs)
    With AsIFrameWorkElement(Sender)
        Select Case CInt(Right$(NewString(.Name).GetString, 1))
            Case 0: Caption = "Hover over Button0"
            Case 1: Caption = "Press on Button1"
            Case 2: Caption = "Click on Button2"
        End Select
    End With
End Sub

---

Attachment 193902

I've been editing the XAML code separately in "XAML Studio" to see real time changes before loading it in the program:

Code:

---

<Grid xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
  <StackPanel x:Name="LayoutRoot" Orientation="Vertical">
    <StackPanel.Background>
      <LinearGradientBrush StartPoint="0,0" EndPoint="0,1">
        <GradientStop Color="Gray" Offset="0"/>
        <GradientStop Color="LightSteelBlue" Offset="1"/>
      </LinearGradientBrush>
    </StackPanel.Background>
    <Button x:Name="Button0" Content="Hover" ClickMode="Hover" Margin="5" Width="150" HorizontalAlignment="Left" Foreground="Gold" FontSize="15" FontWeight="Bold">
      <Button.Background>
        <LinearGradientBrush StartPoint="0,0" EndPoint="1,0">
          <GradientStop Color="DarkViolet" Offset="0.5"/>
          <GradientStop Color="White" Offset="1"/>
        </LinearGradientBrush>
      </Button.Background>
    </Button>   
    <Button x:Name="Button1" Content="Press" ClickMode="Press" Margin="5" Width="150" HorizontalAlignment="Center" Foreground="Blue" FontSize="15" FontWeight="Bold">
      <Button.Background>
        <LinearGradientBrush StartPoint="0,0" EndPoint="0,1">
          <GradientStop Color="Gray" Offset="0"/>
          <GradientStop Color="LightGray" Offset="1"/>
        </LinearGradientBrush>
      </Button.Background>
    </Button>
    <Button x:Name="Button2" Content="Release" ClickMode="Release" Margin="5" Width="150" HorizontalAlignment="Right" Foreground="Red" FontSize="15" FontWeight="Bold">
      <Button.Background>
        <LinearGradientBrush StartPoint="0,0" EndPoint="0,1">
          <GradientStop Color="DarkSlateGray" Offset="0"/>
          <GradientStop Color="LightGray" Offset="1"/>
        </LinearGradientBrush>
      </Button.Background>
    </Button> 
  </StackPanel>
</Grid>

---

So far I've been testing it in VB6 and it works great. I'll import it later in tB as well to see how it performs there.

Yes! Pictures and Examples!

Van, where do you see your XAML islands work taking you? If you could some it up in one paragraph, what benefit would it provide to the average VB6-er? How would you expect it to be used and to what end?

Quote:

---

Originally Posted by SomeYguy

Totally unrelated: Geez I can't believe that its been almost 4 years since you started this thread!. Seems like just yesterday :).

---

Time flies! and it should provide some perspective on how long it takes to accomplish a project or two...

I was reading some old TwinBasic bumph on the optimistic expected timescales re: the TwinBasic IDE/language. I saw that one year was the expected period before we had something in our hands, here we are in 2025 and Wayne is getting close but like all projects, timescales tend to balloon! (no complaints, just an observation).

Your observation on time draws me to another recent post here about newer Microsoft technologies and which we might possibly adopt. I am learning here and I think I'm making good progress but my projects are ever going forward but ever so slow...

It has taken me six months to convert my steampunk clock/calendar from javascript to VB6/RC6.
https://www.vbforums.com/images/ieimages/2025/01/2.jpeg

In my defence, in the same time period I have moved house (twice), been through at least one new personal crises and solved at least three old ones! Upgrading the house, three new cats - and all the rest. I've also converted the clock to TwinBasic.

I don't know if I'm willing to sink massive amounts of time into this but besides the glaring benefit of breathing new life into VB6, sky's the limit no? Even this simple button control blows the original VB6 CommandButton out of the water. There are tons of XAML controls (https://learn.microsoft.com/en-us/do...orkdesktop-4.8) all Unicode-enabled, DPI-aware and already included with Windows, just ready to plug and play. This is the bleeding edge, you can't get a more modern UI than this.

You lose the ability to drag and drop controls like you do in the VB6 IDE, all design is done in XAML code. Probably it would help if I installed some version of Visual Studio .NET, I presume its XAML editor should be a lot better than this free "XAML Studio" from the Microsoft Store.

That is the problem with all projects that extend VB6 towards more modern graphical frameworks, you love the final product but getting there is hard work. We are so used to the RAD nature of the integrated graphical framework that VB6 provides by default that the struggle to implement any another is a real pain by comparison.

My opinion of this XAML direction, is that it needs such a designer. What I mean by that is something that is designed to operate with VB6.

Using Olaf's RichClient to create a graphical UI was painful until he created his simple PSD parser. For me, being very familiar with Photoshop, it is a breeze - but, the absence of a working Forms designer holds it back.

In my recent RC6 creations I use a mix of VB6 forms, VB6 menus and RC graphics, I can't migrate forms and menus fully to RC6 because of the lack of a designer. It is too painful organising the position of every component in code.

Could this be what Olaf is currently working on? He has been very, very quiet for the last few months, Olaf, can we hear from you and find out what you are working on?

Quote:

---

Originally Posted by SomeYguy

Totally unrelated: Geez I can't believe that its been almost 4 years since you started this thread!. Seems like just yesterday :).

---

Your comment caused me to look back over this thread, there is some really interesting programs being worked upon demonstrated here. Perhaps we should open our own webshop and start selling/offering only VB6-derived products...

There is already a very capable visual XAML Designer included in Visual Studio .NET so this isn't a problem. Copilot says:

Quote:

---

Key Features:

- Drag and Drop: You can drag controls from the Toolbox and drop them onto the design surface.

- Properties Window: Allows you to set properties for the selected control, such as size, color, and layout.

- Split View: You can view the design surface and the XAML code side by side. Changes made in the designer are reflected in the XAML code, and vice versa.

- IntelliSense: Provides code completion and suggestions while editing XAML code.

---

Attachment 193903

The real issue is that people already using .NET to create the UI would be crazy to go back and use it in VB6! (well except Franky of course) :D

Quote:

---

Originally Posted by VanGoghGaming

I don't know if I'm willing to sink massive amounts of time into this but besides the glaring benefit of breathing new life into VB6, sky's the limit no? Even this simple button control blows the original VB6 CommandButton out of the water. There are tons of XAML controls (https://learn.microsoft.com/en-us/do...orkdesktop-4.8) all Unicode-enabled, DPI-aware and already included with Windows, just ready to plug and play. This is the bleeding edge, you can't get a more modern UI than this.

You lose the ability to drag and drop controls like you do in the VB6 IDE, all design is done in XAML code. Probably it would help if I installed some version of Visual Studio .NET, I presume its XAML editor should be a lot better than this free "XAML Studio" from the Microsoft Store.

---

It's not like there's no fancy CommandButton controls for VB6, and just about everything on that control list has perfectly nice VB6 controls with near identical functionality. The CodeBank and other VB6 sites are full of ones just as good if not even better than the XAML controls in most cases, also supporting Unicode and DPI-awareness (though system automatic DPI management has long since become good enough it's rarely worth the effort to manage it yourself even if all your controls support that). Then just look at the UIs in VB6 projects like PhotoDemon and XYPlorer. RTB was one of the exceptions... but the new Office one is a pretty good remedy and I've started work on a windowless RTB not needing those.

XAML is the "bleeding edge" today, after a long line of other "bleeding edge" UI control sets pumped out then dropped by Microsoft. It won't be long before the next one supplants XAML. And the dramatic decrease in UI quality from Windows 7 through 11 doesn't make me eager to embrace Microsoft's latest fad. Tried and true basic Win32 UIs with only some minor updates are almost always more functional, look better, and are easier to use.

It's unfortunate the great VB6 controls are scattered about instead of in one centralized package for when there is a legit need for more sophisticated controls... hopefully now that we have a real successor tB's Package Manager can remedy that to some extent. I've also been working on drop in replacements for the unsupportable self-subclass hacks a lot of them use. Then there will also at some point be a new modern UI framework to support cross platform apps.

I really don't see where this adversity comes from. The Button control doesn't count since it's way too simple compared to others. Why would you want third-party controls when you can have all of them already included with the operating system? And didn't the XYPlorer guy say he designed his UI using PictureBoxes and GDI? I mean, that's entirely on another level.

The object-oriented nature of WinRT event handlers completely takes subclassing and thunks out of the equation. Surely you can appreciate that, no?

Quote:

---

Originally Posted by VanGoghGaming

The real issue is that people already using .NET to create the UI would be crazy to go back and use it in VB6! (well except Franky of course) :D

---

I've already uploaded some images here, including ZIP files, which is possible with XAML Islands. Images of these can be found here: https://www.vbforums.com/showthread....=1#post5623743 The images are also quite small, but you can see in one of the images that the button can even be tilted and rotated. Rounded corners, for example for a button or text box, are no problem in XAML.

@VanGoghGaming People shouldn't switch back from .NET to VB6. :D I just wanted to show that XAML also works in VB6, and therefore also in TwinBasic. What is ultimately missing is a corresponding XAML designer for VB6 or for TwinBasic that creates the XAML string. Alternatively, you can create corresponding XAML controls via the XAML interfaces instead of a XAML string.

I completely agree with Faf. The scattering of effort and the lack of direction/focus has always sabotaged VB6's efforts to be taken more seriously. It 'can' do everything but all that knowledge has to be gathered in bit by bit by each and every individual programmer, whereas it is all in one place under the bigger frameworks that wrap everything under the .NET umbrella.

In VB6 once you eventually find your own personal toolkit you can do some amazing stuff, I think we've all proven that here on this thread, ie. such an amazing group of apps demonstrated here.

It does take someone like Wayne and his direction/capability to bring it all together.

Quote:

---

Then there will also at some point be a new modern UI framework to support cross platform apps.

---

Who'd have thought that, just four or five years ago?

Quote:

---

Originally Posted by -Franky-

I've already uploaded some images here, including ZIP files, which is possible with XAML Islands. Images of these can be found here: https://www.vbforums.com/showthread....=1#post5623743 The images are also quite small, but you can see in one of the images that the button can even be tilted and rotated. Rounded corners, for example for a button or text box, are no problem in XAML.

---

I don't see any ZIP files there, I would really like to take a look at your XAML code for those controls, you obviously have so much more experience...

Quote:

---

Originally Posted by -Franky-

What is ultimately missing is a corresponding XAML designer for VB6 or for TwinBasic that creates the XAML string.

---

That is what is needed, we have the TB designer, perhaps the first step is a converter from the (JSON?) format that it creates, into a XAML format.

There must be, somewhere, an open source graphical interface designer that could form the basis of a separate designer that can handle the extended capabilities of XAML based forms.

In truth though, I don't see many current MS -inspired apps using such gradients and fancy graphics. I just see square unadorned boxes with a blue background or a white background, devoid of features with big bold text.

I am sure we can bang something out that matches the graphical quality without all the underlying hoohah. A simple converter might be the way to go which you can add functionality as it is required. Olaf has created such a one-way converter to convert traditional VB6 forms and some of its controls to RC/forms and widgets.

Quote:

---

Originally Posted by VanGoghGaming

I don't see any ZIP files there, I would really like to take a look at your XAML code for those controls, you obviously have so much more experience...

---

It could also be that the ZIPs are buried in other threads. Whatever. This ZIP only uses the XAML interfaces. As you can see, there are a lot of classes and only a few controls (without events) are finished so far. I'm not working on this project any more because it's just too extensive for me alone.

Quote:

---

Originally Posted by VanGoghGaming

I really don't see where this adversity comes from. The Button control doesn't count since it's way too simple compared to others. Why would you want third-party controls when you can have all of them already included with the operating system? And didn't the XYPlorer guy say he designed his UI using PictureBoxes and GDI? I mean, that's entirely on another level.

The object-oriented nature of WinRT event handlers completely takes subclassing and thunks out of the equation. Surely you can appreciate that, no?

---

Because using those 3rd party controls is easier and the source is right there for any customization you might want to make. Everything for them is also included in the OS. It's just a matter of importing prewritten code modules-- something you also need to do to host XAML controls... dropping in a few usercontrols is no different than dropping in the dozens of modules and interface defs to support XAML or WinRT, and the code you're importing is generally simpler and much more easy to extend vs writing the extensive work required for everything XAML and WinRT. I can't understand how one could view WinRT dynamic template-based interface conversions for events as simpler than a traditional subclass unless you're using them in .NET (see -Franky-'s last comment), which honestly seems like it should be the end result if you strongly prefer the way .NET controls operate and isolate you from the low level implementation. For me, that's the whole point of VB6 and now tB... to have the high level RAD without giant roadblocks and massive ever-changing frameworks getting between you and dropping into the low level details when you need to. There's nothing inherently wrong with preferring the .NET way, but then why not just use .NET?

Man, poor uncleber is gonna be maaaad with us now because we're definitely straying wayy off topic :D

No, I agree with you. That's why I am not going in that direction, seems like a lot of hassle just to portray some dull, unadorned bland boxes on a win !! (sic) machine somewhere. I can produce more or less anything in Photoshop and VB6 and I don't need compatibility with current/future tech, so for me, the question is, why bother?

I think that for VB6 to find its niche it needs to be used for doing things that aren't being done well enough by others.

That brings us straight back to "Which VB6 projects are you working on?"

I suppose what we should do is to invite Wayne to tell us what he is working on with regard to VB6 / TwinBasic as its future incorporates a lot of what we are now discussing.

- and that allows me to drop in an image of the TwinBasic IDE beta 645, with the light theme for VB6bold (modified), the two forms I am working on now, and the GDI+ steamyDock at the bottom which is now TwinBasic too.

https://www.vbforums.com/images/ieimages/2025/01/3.jpeg

As I understand it, The TB IDE is written in TwinBasic, (Faf. you can correct me if I am incorrect) but the monaco editor itself is written in javascript and embedded somehow.

Quote:

---

Originally Posted by fafalone

I can't understand how one could view WinRT dynamic template-based interface conversions for events as simpler than a traditional subclass unless you're using them in .NET (see -Franky-'s last comment), which honestly seems like it should be the end result if you strongly prefer the way .NET controls operate and isolate you from the low level implementation. For me, that's the whole point of VB6 and now tB... to have the high level RAD without giant roadblocks and massive ever-changing frameworks getting between you and dropping into the low level details when you need to. There's nothing inherently wrong with preferring the .NET way, but then why not just use .NET?

---

I still don't understand what dynamic interfaces you keep referring to. Every single event interface I've encountered (hundreds so far) has been extremely well defined with its own unique IID and there's no mistaking it (I don't even think it would work any other way). I've even posted examples of using such WinRT events in VB6 as well as tB. In fact this is the appeal of WinRT, other than that I wouldn't stray from the VB6/tB syntax that allows far more freedom than managed code, so moving to .NET is a no-go for all the reasons you mentioned yourself in many other threads.

These XAML controls just look too good to pass and their functionality is flawless (you won't see the dreaded "Automation Error" DLL-Hell ever!). They even support the currently selected system theme on the fly (Light/Dark). Here's how a TextBox with context menu looks like in each theme:

Attachment 193906
Attachment 193907

I wouldn't want to simulate all that in PhotoShop if it can be helped! Even if Microsoft will come up with another Framework in the future they always keep 100% backward compatibility with everything they released in the past. Hell even your Ribbon from the stone age still works! :D

Quote:

---

Man, poor uncleber is gonna be maaaad with us now because we're definitely straying wayy off topic :D

---

I made sure to post screenshots, so I'm in the clear! ;)

Quote:

---

Originally Posted by VanGoghGaming

Hell even your Ribbon from the stone age still works! :D

---

That is SO cruel.

Quote:

---

Originally Posted by VanGoghGaming

I wouldn't want to simulate all that in PhotoShop if it can be helped!

---

Nor me! I only do it for my own contrived interfaces.

Quote:

---

Originally Posted by VanGoghGaming

I made sure to post screenshots, so I'm in the clear! ;)

---

You are in the clear.

So Van, what do you suggest? What 'should' we be doing to implement such lovely controls/events in VB6?

The implementation part is piece of cake (see the XAML Buttons code complete with Click events that I posted earlier). What you can't see in that example are the dozens of interfaces translated from the Windows SDK into VB syntax but I'll post a tB project shortly including those interfaces for everyone interested in having a peak. Like Franky said it's a lot of work since the SDK is so vast but even the WinDevLib wasn't made in a day! ;)

So, ultimately, to be usable, do you expect that there ought to be a separate XAML designer that TB or VB6 can use and then a 'package' that allows TB to harness the properties and events, or for VB6, a series of classes and modules that would allow VB6 the same access? Or do you think it is only sensible to think of TB as the target?

Well for IID-free templates you don't even have to get into events. Take a simple bitmap interface... what's the IID for the interface returned for the FileExtensions member of IBitmapCodecInformation?

But did you just say there's *dozens* of interfaces you had to translate just to get a button with clicks?

That's why i didn't pursue it. You either custom write only minimal implementations with exactly the things you want, which is only the dozen of interfaces full of stubs, or you'll have a WinDevLib-sized project for just a fraction of the most common items.

Quote:

---

(you won't see the dreaded "Automation Error" DLL-Hell ever!)

---

With the exception of the closed source stuff, you never get this issue with UserControls if you use them as their .ctl source in your project, which I always do unless I have absolutely no practical alternative to a closed source component, which is very rare. The typelibs by me, krool, and The trick don't have serious registration issues because we avoid associating GUIDs with structs and enums which triggers the more complicated registration issues.

But also, I've encountered plenty of apps that demand I install some specific version of the .NET Framework because it didn't come with Win10. And the dependency hell in VS for this stuff makes VB6 active-x dll hell seem like a fun time.

Quote:

---

Originally Posted by VanGoghGaming

Even this simple button control blows the original VB6 CommandButton out of the water. There are tons of XAML controls (https://learn.microsoft.com/en-us/do...orkdesktop-4.8) all Unicode-enabled, DPI-aware and already included with Windows, just ready to plug and play. This is the bleeding edge, you can't get a more modern UI than this.

---

Now you have an idea of at least some of things that drew a lot of us to .Net. WPF programmers for example have been enjoying these things for years. ;)

Quote:

---

Originally Posted by fafalone

But also, I've encountered plenty of apps that demand I install some specific version of the .NET Framework because it didn't come with Win10. And the dependency hell in VS for this stuff makes VB6 active-x dll hell seem like a fun time.

---

I can't install my favourite game any more due to it requiring earlier components namely Microsoft .NET Framework 3.5, Microsoft XNA Framework Redistributable 3.1. Can't even find those any more and when you do the versions just don't install on later Windows
https://www.vbforums.com/images/ieimages/2025/01/9.png

I have to keep an old Win 7 laptop just to play this game.

Quote:

---

Originally Posted by Niya

Now you have an idea of at least some of things that drew a lot of us to .Net. WPF programmers for example have been enjoying these things for years. ;)

---

What are you working on Niya?

Quote:

---

Originally Posted by yereverluvinuncleber

What are you working on Niya?

---

I haven't done anything in a while with regard to programming. The last thing I was working on for VB6 was a pet project intended for the CodeBank, something like a hash table if I remember correctly. I might get around to finishing that if I ever get the mood.

Quote:

---

Originally Posted by yereverluvinuncleber

That is what is needed, we have the TB designer, perhaps the first step is a converter from the (JSON?) format that it creates, into a XAML format.

---

You actually don't need a designer, not as much as you would for VB6/WinForms style project anyway. It's nice to have but not essential. There are some .Net 3rd party project types that use XAML but don't provide a designer. In these cases, we just run the program to see what it looks like and sometimes we get a hot-reload feature where changes in the XAML are reflected while the program is running.

Quote:

---

Originally Posted by fafalone

Well for IID-free templates you don't even have to get into events. Take a simple bitmap interface... what's the IID for the interface returned for the FileExtensions member of IBitmapCodecInformation?

---

That's as straightforward as it gets. The FileExtensions property of IBitmapCodecInformation returns an IVectorView_HSTRING (that is to say a read-only array of strings) with an IID of:

Code:

---

2F13C006-A03A-5F69-B090-75A43E33423E

---

This IVectorView_HSTRING interface is rather ubiquitous, you'll find it in many places since arrays of strings are always in demand. As I've mentioned before (also told you on Discord in response to your GitHub comments about these elusive "dynamic" interfaces which turned out to be rather static in the end), all WinRT interfaces are well-defined and neatly organized. You only need to write them once and then you can use them forever. I'd say it's worth the hassle:

Code:

---

[InterfaceId("2F13C006-A03A-5F69-B090-75A43E33423E")]
Interface IVectorView_HSTRING Extends IInspectable
    Function GetAt(ByVal Index As Long) As LongPtr
    Property Get Size() As Long
    Function IndexOf(ByVal hString As LongPtr, Index As Long) As Boolean
    Function GetMany(ByVal StartIndex As Long, ByVal Length As Long, Items As LongPtr) As Long
End Interface

[InterfaceId("400CAAF2-C4B0-4392-A3B0-6F6F9BA95CB4")]
Interface IBitmapCodecInformation Extends IInspectable
    Property Get CodecId() As UUID
    Property Get FileExtensions() As IVectorView_HSTRING
    Property Get FriendlyName() As LongPtr
    Property Get MimeTypes() As IVectorView_HSTRING
End Interface

[InterfaceId("438CCB26-BCEF-4E95-BAD6-23A822E58D01")]
Interface IBitmapDecoderStatics Extends IInspectable
    Property Get BmpDecoderId() As UUID
    Property Get JpegDecoderId() As UUID
    Property Get PngDecoderId() As UUID
    Property Get TiffDecoderId() As UUID
    Property Get GifDecoderId() As UUID
    Property Get JpegXRDecoderId() As UUID
    Property Get IcoDecoderId() As UUID
    Function GetDecoderInformationEnumerator() As IVectorView_BitmapCodecInformation
    Function CreateAsync(ByVal RandomAccessStream As IRandomAccessStream) As IAsyncOperationBitmapDecoder
    Function CreateWithIdAsync(ByVal Data1 As Long, ByVal Data2 As Long, ByVal Data3 As Long, ByVal Data4 As Long, ByVal RandomAccessStream As IRandomAccessStream) As IAsyncOperationBitmapDecoder
End Interface

---

If you wanted to enumerate all BitmapDecoders available in your system as well as their supported file extensions, you would call the GetDecoderInformationEnumerator of the IBitmapDecoderStatics interface:

Code:

---

Friend Function GetDecoderInformation() As Collection
Dim i As Long, j As Long, sFileExtensions As String
    Set GetDecoderInformation = New Collection
    With BitmapDecoderStatics.GetDecoderInformationEnumerator
        For i = 0 To .Size - 1
            With .GetAt(i).FileExtensions
                sFileExtensions = vbNullString
                For j = 0 To .Size - 1
                    sFileExtensions = sFileExtensions & NewString(.GetAt(j)).GetString & IIf(j < .Size - 1, ", ", vbNullString)
                Next j
            End With
            GetDecoderInformation.Add NewString(.GetAt(i).FriendlyName).GetString & " (" & sFileExtensions & ")"
        Next i
    End With
End Function

---

and the result should be something like this:

Attachment 193910

See to me it's not so straightforward when the definition is Windows.Foundation.Collections.IVectorView<HSTRING>** value), that GUID doesn't exist in windows.foundation.collections.h, and you have to hunt it down elsewhere where it's not in a regular interface format, but instead obtained from

Code:

---

#ifndef DEF___FIVectorView_1_HSTRING_USE
#define DEF___FIVectorView_1_HSTRING_USE
#if !defined(RO_NO_TEMPLATE_NAME)
namespace ABI { namespace Windows { namespace Foundation { namespace Collections {
template <>
struct __declspec(uuid("2f13c006-a03a-5f69-b090-75a43e33423e"))
IVectorView<HSTRING> : IVectorView_impl<HSTRING>
{
    static const wchar_t* z_get_rc_name_impl()
    {
        return L"Windows.Foundation.Collections.IVectorView`1<String>";
    }
};

---

which you then have to combine with the plain IVectorView interface that *is* where the interface says it is, not neatly defined like the codec info interface, and is instead:

Code:

---

    template <class T>
    struct IVectorView_impl<T, false> : IInspectable /* requires IIterable<T> */
    {
    private:
        typedef typename Windows::Foundation::Internal::GetAbiType<T>::type    T_abi;
        typedef typename Windows::Foundation::Internal::GetLogicalType<T>::type T_logical;
    public:
        typedef T                                                              T_complex;

        virtual HRESULT STDMETHODCALLTYPE GetAt(_In_ unsigned index, _Out_ T_abi *item) = 0;
        virtual /* propget */ HRESULT STDMETHODCALLTYPE get_Size(_Out_ unsigned *size) = 0;
        virtual HRESULT STDMETHODCALLTYPE IndexOf(_In_opt_ T_abi value, _Out_ unsigned *index, _Out_ boolean *found) = 0;
        virtual HRESULT STDMETHODCALLTYPE GetMany(_In_  unsigned startIndex, _In_ unsigned capacity, _Out_writes_to_(capacity,*actual) T_abi *value, _Out_ unsigned *actual) = 0;
    };

---

. "That's as straightforward as it gets. " -- yup, you can't see the issue there?

I'm glad you find that straightforward and "well defined and neatly organized" (LOL) but to me it's a much bigger pain than just going through WIC, which is almost certainly what it's abstracting. And something that would be extremely difficult to make an automated tool for... WDL wouldn't have been possible as a one-man hobby project if I didn't have a bunch of routines to partially convert stuff.

I can see the issue there and I don't pretend to understand any more than you do. As far as I've gathered there are many types of such IVectorView interfaces and they all have those 4 methods. The only difference is the datatype they handle (HSTRING in this case). I've also noticed there is a distinct GUID for each type of IVectorView and that it's not hard to find. VB/tB are not smart enough to use generic types like that so you need to explicitly declare this interface for each type you want to use and its corresponding GUID (there's quite a few but not that many). Other than that I don't know what to say.

@yereverluvinuncleber It was not my intention to start what I consider to be a pointless discussion about whether or not to use WinRT, XAML etc. Somehow it reminds me of pointless discussions about whether .NET, VB6 or now TB is the better programming language. I would suggest that the discussion can be continued in my thread. -> https://www.vbforums.com/showthread....=1#post5667572

Good Man Franky! Thankyou. Feel free to post an image and a description of whatever you achieve, it is all interesting.