BBR Update

Today I finished a major cleanup of the station management system.

Previously, stations automatically disabled by the validation thread and stations manually removed by the user were mixed together in the same file.

This has now been split into:

US_stations.lst   = master station list
US_favorite.lst   = favorites
US_broken.lst     = automatically detected bad URLs
US_removed.lst    = stations permanently removed by the user

This means:

• A dead station is no longer confused with a user deletion.
• User choices are preserved.
• Broken stations can be rechecked independently.
• Future restore and maintenance tools become possible.

I also added a small station statistics dialog showing:

Stations
Active
Broken
Removed
Favorites

The stream checker has also been improved and now distinguishes temporary network failures from more serious URL errors.

As usual, the attachment linked to the first post of this trhead has been updated.

A small change internally, but an important step toward making BBR more reliable and easier to maintain.

BassBox Radio 4.00

Version 4.00 is a complete rewrite of BassBox Radio.

The original version was written with WinDev in 2014.
This new version has been fully rewritten in native C/C++ with a major size reduction, producing a tiny 62 KB executable.



Despite its very small size, BBR 4.00 includes:

• Integrated Internet radio station browser
• Favorites management
• Country filtering
• Embedded WebView2 browser
• OpenGL visual plugin support
• Realtime oscilloscope
• GDImage/WinLIFT composited interface
• Very low resource usage
• Native Win32 responsiveness

The oscilloscope and rendering system are fully hardware accelerated and continue updating smoothly even while moving or resizing the window.

This version is based on my own native libraries:

• WinLIFT
• GDImage
• BassBox audio engine

Everything has been designed to remain lightweight, reactive and visually clean without relying on heavy frameworks.

The full VS2022 project is attached to this post.

If you download it and test it, please give me your feedback.
I would be interested to know if you find any oddities, bugs, or if you have suggestions for improvement.

Runtime activation of Common Controls v6 (Manifest-free alternative)

For years, the standard way to enable modern Windows visual styles (ComCtl32 v6) has been through a manifest, either embedded or via:

// Include the v6 common controls in the manifest
#pragma comment(linker,""/manifestdependency:type='win32'
name='Microsoft.Windows.Common-Controls' version='6.0.0.0'
processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'"")

While this works, it introduces a dependency on the linker and can sometimes lead to inconsistent behavior depending on build settings, resources, or memory conditions.


Alternative: Runtime activation (no manifest required)

It is possible to activate visual styles dynamically at runtime using an activation context (ACTCTX).
This method loads the ComCtl32 v6 resources directly from shell32.dll.

static HANDLE    g_hActCtx = INVALID_HANDLE_VALUE;
static ULONG_PTR g_ulActCookie = 0;
static BOOL      g_bActCtxActive = FALSE;

static BOOL EnableVisualStylesRuntime(VOID) {
    WCHAR dir[MAX_PATH];
    DWORD cch = GetSystemDirectory(dir, MAX_PATH);
    if (!cch || cch >= MAX_PATH) return FALSE;

    ACTCTX actCtx; ClearMemory(&actCtx, sizeof(actCtx));
    actCtx.cbSize = sizeof(actCtx);
    actCtx.dwFlags = ACTCTX_FLAG_RESOURCE_NAME_VALID | ACTCTX_FLAG_ASSEMBLY_DIRECTORY_VALID;
    actCtx.lpSource = TEXT("shell32.dll");
    actCtx.lpAssemblyDirectory = dir;
    actCtx.lpResourceName = MAKEINTRESOURCE(124);

    g_hActCtx = CreateActCtx(&actCtx);
    if (g_hActCtx == INVALID_HANDLE_VALUE) return FALSE;

    if (!ActivateActCtx(g_hActCtx, &g_ulActCookie)) {
        ReleaseActCtx(g_hActCtx);
        g_hActCtx = INVALID_HANDLE_VALUE;
        return FALSE;
    }

    g_bActCtxActive = TRUE;
    return TRUE;
}

static VOID DisableVisualStylesRuntime(VOID) {
    if (g_bActCtxActive) {
        DeactivateActCtx(0, g_ulActCookie);
        g_bActCtxActive = FALSE;
        g_ulActCookie = 0;
    }

    if (g_hActCtx != INVALID_HANDLE_VALUE) {
        ReleaseActCtx(g_hActCtx);
        g_hActCtx = INVALID_HANDLE_VALUE;
    }
}


Important notes

* Must be called very early (ideally at the start of wWinMain or inside your core init like skInitEngine).
* Affects all subsequently created controls (ComboBox, ListView, TreeView, etc.).
* Ensures consistent theming without relying on external manifests.
* Particularly useful in:
   - CRT-free builds
   - DLL-based UI engines (e.g. WinLIFT)
   - Custom control frameworks
* Avoid calling it after controls are already created.


Why this matters

In practice, inconsistent behavior of controls (especially owner-drawn or themed ones) often comes from:

* Missing or partial v6 activation
* Timing issues (controls created before activation)
* Resource/memory edge cases

By forcing activation at runtime, behavior becomes deterministic and uniform.


Conclusion

This approach is a reliable replacement for manifest-based activation and gives full control over when and how visual styles are enabled.

In my case, integrating this directly into the initialization phase removed all inconsistencies without requiring any manifest handling.


Tip

If you already use a framework like WinLIFT, placing this call inside the engine initialization guarantees that all controls benefit from v6 styling automatically.

This is a small demo to expose the use of zBrowser with a skinned application.

The use of WinLIFT/GDImage is a mandatory to render the thumbnails (images, .orb thumbnail, audio tag cover art).
It is also important to use Common Controls (ComCtl32 v6), to use skinned combo drop down.

You can select one file, or several if you hold down the CTRL key while clicking on thumbnails.
Use right mouse click, to popup the contextual menu, to fire a specific actions.

Drag and drop, is available from a mouse wheel click, to drop a thumbnail onto MBox64 or ObjReader64 (audio, image, .orb, .obj, folder).
A complete folder audio, could be used with Mbox64.
That would work with any application using the classic DragAcceptFiles.

zBrowser – Lightweight Win32 File Dialog Replacement

I’ve just integrated a new feature into my custom file dialog zBrowser, used across my apps (MBox64, ObjReader, etc.).



What it is:
A fully custom, skinned, Win32 file explorer built on top of GDImage + WinLIFT, designed to replace the standard Open/Save dialog with something faster, cleaner, and fully controllable.

Key features:

* ✔ Dual view: List / Thumbnails (with real previews)
* ✔ Native shell icons + overlays
* ✔ Fast folder navigation (TreeView + ListView sync)
* ✔ Multi-selection support
* ✔ Built-in media detection (audio, image, ORB, etc.)
* ✔ Custom popup menu ("Open with", Properties, etc.)
* ✔ Persistent state (folder, sorting, view mode)

New addition: Drag & Drop (2 KB only)

* ✔ Custom drag visual (layered window, alpha = 200)
* ✔ Multi-file drag (true MULTI_SZ → CF_HDROP)
* ✔ Works between my apps (MBox64 ⇄ ObjReader)
* ✔ No OLE / COM / ATL / MFC
* ✔ Pure Win32 (WM_DROPFILES)

Design philosophy:

* No bloat
* No hidden frameworks
* Full control
* Maximum reuse of existing engine code

Everything is built using existing GDImage objects (selection, thumbnails, labels), so there is zero duplication and perfect consistency across applications.

Limitations (by design):

* Does not target Explorer / modern apps (DirectUIHWND)
* OLE drag & drop intentionally avoided to keep things lightweight

Result:
A fast, clean, and fully controllable file dialog with integrated drag & drop, all in a minimal footprint.

---

This is now the default file interface for my toolchain.