<![CDATA[Stories by No Longer Set on Medium]]> https://medium.com/@NoLongerSet?source=rss-78acf5965d4c------2 https://cdn-images-1.medium.com/fit/c/150/150/0*YWCCLWQaVirS31Pz.jpg Stories by No Longer Set on Medium https://medium.com/@NoLongerSet?source=rss-78acf5965d4c------2 Medium Sat, 16 May 2026 10:20:59 GMT <![CDATA[Merry Christmas]]> https://medium.com/@NoLongerSet/merry-christmas-2809e19712a0?source=rss-78acf5965d4c------2 https://medium.com/p/2809e19712a0 Tue, 26 Dec 2023 04:12:30 GMT 2023-12-26T04:12:30.204Z “The Word became flesh and made his dwelling among us. We have seen his glory, the glory of the one and only Son…”

By Mike Wolfe (connect on Twitter: @NoLongerSet)

John 1:1–14

The Word Became Flesh

1 In the beginning was the Word, and the Word was with God, and the Word was God. 2 He was with God in the beginning. 3 Through him all things were made; without him nothing was made that has been made. 4 In him was life, and that life was the light of all mankind. 5 The light shines in the darkness, and the darkness has not overcome it.

6 There was a man sent from God whose name was John. 7 He came as a witness to testify concerning that light, so that through him all might believe. 8 He himself was not the light; he came only as a witness to the light.

9 The true light that gives light to everyone was coming into the world. 10 He was in the world, and though the world was made through him, the world did not recognize him. 11 He came to that which was his own, but his own did not receive him. 12 Yet to all who did receive him, to those who believed in his name, he gave the right to become children of God — 13 children born not of natural descent, nor of human decision or a husband’s will, but born of God.

14 The Word became flesh and made his dwelling among us. We have seen his glory, the glory of the one and only Son, who came from the Father, full of grace and truth.

Originally published at NoLongerSet.com

]]> <![CDATA[twinBASIC Update: December 24, 2023]]> https://medium.com/@NoLongerSet/twinbasic-update-december-24-2023-2ef71bf2d1d0?source=rss-78acf5965d4c------2 https://medium.com/p/2ef71bf2d1d0 Sun, 24 Dec 2023 19:56:51 GMT 2023-12-24T19:56:51.229Z Highlights include an updated twinBASIC roadmap, a sneak peek at upcoming IDE menu and docking improvements, and RadioMan — a new tB project from fafalone.

By Mike Wolfe (connect on Twitter: @NoLongerSet)

On April 23, 2021, I helped Wayne Phillips introduce the world to twinBASIC at the Access DevCon Vienna conference. I boldly predicted that twinBASIC (along with the Monaco editor) would replace VBA and its outdated development environment by 2025. With that goal in mind, this weekly update is my attempt to keep the project fresh in the minds of the VBA development community.

Every Sunday, I will be providing updates on the status of the project, linking to new articles discussing twinBASIC, and generally trying to increase engagement with the project. If you come across items that should be included here, tweet me @NoLongerSet or email me at mike at nolongerset dot com.

Here are some links to get involved with the project:

Highlights

twinBASIC Roadmap Updated

Wayne updated the twinBASIC roadmap this week for the first time since June.

The bad news is the v1 release date has been pushed back to July 1, 2024 (was previously January 3, 2024).

The good news is that:

  • The project continues making steady progress
  • v1 Release Candidate builds are scheduled for Q2 2024 (April — June)
  • Edit & Continue support will now be available with v1 (previously this was a post-v1 feature)
  • Limited vbWatchdog support will be available with v1 (full support will be implemented shortly after the v1 release)
  • Wayne is not rushing out a half-baked product simply to meet an arbitrary deadline
  • The IDE is getting a lot more love than I expected for the version 1 release

I think the last point is important.

As the saying goes, you only get one chance to make a first impression.

And, fair or not, software applications are disproportionately judged based on the physical appearance of their user interface. What Wayne has accomplished with the twinBASIC compiler is nothing short of amazing. That said, the official v1 release is likely to draw in a surge of tire-kickers interested in the new language. That audience, in particular, is likely to make a lot of assumptions about the language based purely on the development environment.

I have a hunch that Wayne came to a similar conclusion and that is why he prioritized some of the more advanced IDE features (like fully customizable layouts as described below) to be available at launch.

For posterity, here is the current state of the twinBASIC roadmap. As always, dates and features are subject to change:

2024-Q1 (JAN-MAR)

  • Add MDI Forms support
  • Finalize UserContol / ActiveX support
  • Finish all remaining basic controls
  • Complete the missing App object methods
  • Add Printer/Printers support
  • Add the missing features to the new IDE, e.g. rename-refactoring and Test Explorer

2024-Q2 (APR-JUN)

  • Finish LLVM support, for optimized builds
  • v1 Release Candidate builds available within this period

VERSION 1 RELEASE

  • Tentative Release Date: 1st July 2024

2024-Q3 (JUL-SEP)

  • Start Analysis Extension API
  • Support full inheritance (#73)
  • Add full vbWatchdog support
  • Add multi-threading syntax support
  • Start cross-platform support for x86/x64 Linux/Mac

2024-Q4 (OCT-DEC)

  • Start cross-platform support for ARM Linux/Mac/Android
  • Start of reimplementation of all remaining VB6 shipped controls, such as Winsock, MAPI, Adodc, DataGrid, MSCOMM, etc
  • Support ActiveX controls on tB forms with unmatched bitness, using a proxy-process (e.g. 64-bit app using a 32-bit ActiveX control)

Upcoming IDE Docking Features

From Wayne in Discord:

The docking feature has been completely rewritten. It is extremely flexible, and should accomodate our current and future needs (for things like multi code editor support). Additionally:

  • all panels can now be closed/shown individually
  • the toolbar is also now docked and movable
  • dragging the title bar of a panel brings it into “floating” mode.
  • Using the grab icon brings it back into docked mode

As seen in the video, there’s a couple of quirks when going from floating mode back to docked mode, but these will of course be fixed before release

Click image to view video.

I think my favorite review of the upcoming docking feature came from Andrew Mansell (aka, mansellan):

Damn, that’s sweet.

So wait… @WaynePhillipsEA looked at the docking system for VS2022 and thought: hold my beer.

Nice.

New Default IDE Layout

Obviously, this is still a work in progress. But the new default layout for the twinBASIC IDE will look like this:

The good news is that this is just a starting point.

You will be able to save and restore custom layouts. You will also be able to restore the default layout in case you get yourself into trouble customizing things.

Once keybindings are introduced, you will be able to easily switch between layouts. This will let you, for example, have a development layout and a debugging layout that you can quickly switch between depending on what you are doing at the time.

Improved Menus

Wayne: “Menus are now receiving some love…”

Click image to view video.

Discord Chat Summary

* Auto-generated via Claude-2–100k on poe.com

Here is a summary of the key points from the General channel transcript:

twinBASIC General Channel Summary

Over the past week, the twinBASIC team made significant progress on the IDE UI overhaul. New features were showcased including a rewritten docking system, movable toolbar, tabbed menus, and an updated default layout. Multiple screenshots and videos demonstrated the new capabilities.

Discussions highlighted:

  • The new docking system is extremely flexible and will support future features like multiple code windows. Panels can be individually opened/closed, floated, and docked.
  • The toolbar is now docked and movable. The layout leaves room for more buttons. Extra toolbars can be easily added.
  • Menus received visual updates and now support tabs for better organization. More menu options will be enabled soon.
  • The default IDE layout was tweaked based on feedback to expand the Problems pane and consolidate the Debug Console on the left. This will likely become the standard layout.
  • Support was confirmed for passing Decimal types ByVal to APIs, enabling stopgap 32/64 bit support for UDTs like RECT until full ByVal UDT marshaling is implemented.
  • Multiple IDE windows are planned for v1 now thanks to the docking system changes. At minimum a split view code editor is desired.
  • The team continues to consider open sourcing parts of the project, starting with the IDE components first. Community feedback on licensing options was gathered.

Overall, rapid progress is being made to overhaul the IDE and prepare for the next major release. The team aims to provide a modern, flexible interface while retaining the familiarity of the Visual Basic origins. Community excitement is building in anticipation of the upcoming version.

Around the Web

twinBASIC Features List

Jon Johnson (aka, fafalone) has been lovingly maintaining the twinBASIC Features page on the tB wiki.

The Features page is not new this week, but it did come up in the Discord chat. It’s been a long time since I’ve linked to it, so I thought it was worth mentioning again.

The page is broken down into the following sections:

The features listed are “new” in the sense that they do not exist in VBA/VB6.

RadioMan — Radio Management

fafalone is back with another twinBASIC sample project. Unlike many of his others, which have been twinBASIC ports of code originally written for VB6, the RadioMan project was written from the ground up in twinBASIC.

Here’s his announcement from the show-and-tell channel of the tB Discord server:

This app exposes undocumented radio management functionality in Windows. I’ve always been a big fan of making your own settings apps, so don’t like being told the official one is the only way to do something. The IMediaRadioManager, IRadioInstance, and IRadioCollection interfaces are documented, but the coclasses representing the system objects actually implementing them are not; they're just documented for hardware providers to provide. There's three of these I could find: the WWAN manager, which includes cellular radios, the WLAN manager, which includes WiFi radios, and the Bluetooth manager (self explanatory). These provide control over individual radios. I tested this app on my Surface tablet, where I had one of each. The app lets you control them all individually; you choose one on the list then can query, enable, or disable. Also available is the IRadioManager interface that controls the master switch for all radios - 'Airplane Mode', you can also enable/disable this mode.

Changelog

Here are the updates from the past week. You can also find this information by visiting the GitHub twinBASIC Releases page.

Releases · WaynePhillipsEA/twinbasic

Contribute to WaynePhillipsEA/twinbasic development by creating an account on GitHub.

GitHubWaynePhillipsEA

No new releases this week.

Originally published at NoLongerSet.com

]]> <![CDATA[Week in Review: December 23, 2023]]> https://medium.com/@NoLongerSet/week-in-review-december-23-2023-78a1c91323b1?source=rss-78acf5965d4c------2 https://medium.com/p/78a1c91323b1 Sat, 23 Dec 2023 19:03:27 GMT 2023-12-23T19:03:27.368Z Highlights include an MZ-Tools tour from developer Carlos Quintero, an Edge browser control video series, and multi-select filtering of a continuous form.

By Mike Wolfe (connect on Twitter: @NoLongerSet)

Just Published

This section includes videos, articles, and interesting discussions from the past 7 days.

Articles

Videos‌

New to Me

This section includes content I discovered this week that has been around for awhile.

Upcoming Access User Group Events

NOTE: Only English-language user group meetings with scheduled guest speakers or topics are listed. For a complete list of upcoming events, visit the Access User Group event calendar.

  • January 3, 2024: Ramachandran (A.P.R.) Pillai — Streamlining the Form Module Code in the standalone Class Module
  • January 4, 2024: Kent Gorrell — The Power of Sub classes in Access VBA
  • February 7, 2024: Carlos Quintero — Features of MZ-Tools to make you more productive with VBA
  • March 6, 2024: Thomas Möller — Better Access Charts in the new Edge Browser Control
  • March 15, 2024: Access Day — one-day in-person Access Conference in Seattle, WA area (JUST ADDED)
  • April 3, 2024: Dale Fye — Working with Command Bars and the Access Shortcut Tool
  • April 18–19, 2024: Access DevCon Vienna — (Online in Microsoft Teams) Agenda to be announced
  • May 1, 2024: Colin Riddington — View & Edit Import/Export (IMEX) Data Task Specifications

‌

Access Roadmap

There were NO CHANGES to the roadmap between the last Week in Review (2023–12–16) and this one (2023–12–23).

The development priorities were last updated at the German-language AEK conference on October 14, 2023.

Listed below is a snapshot of the official Access Roadmap.

“In Development”, “Rolling Out”, and “Launched” are Microsoft terms that I pulled straight from the public roadmap.

“Development Priorities” do not appear on the Access Roadmap. Instead, they get updated from time to time in official Access blog posts or Access engineering team presentations. I’ll include a link to the source of the current development priorities as they get updated.

Development Priorities

The items listed below reflect Microsoft’s order of priority and were published in the following article, Microsoft’s Plans for Access in the Next 6 Months.

The items are listed in priority order according to Principal Engineering Manager Dale Rector. The “Expected Benefit” of each feature is shown in italics after the description of the feature itself.

New priorities added since the previous set of priorities are shown in bold below. Dropped priorities are struck through.

  1. Continued Focus on Monthly Issue Fixes: (Monthly Issue Fix Blog) Improved product quality and reliability
  2. Access becomes Large Address Aware: Removal of key customer error issue
  3. Dataverse export improvements: Make it easier and faster for admins to migrate their data to Dataverse
  4. Large monitor support for forms: Improved support of Access on the latest hardware
  5. Modern Chart Improvements: Expanded support for the most popular chart types and options
  6. SQL Editor Improvements: Significantly improved SQL query editing experience
  7. Inconsistent Database Error Fix

Special thanks to Karl Donaubauer for posting the updated priorities at AccessForever.org.

In Development

Rolling Out

None.

Launched

  • APR 2023: Modern Web Browser Control
  • MAR 2023: New Modern Web Browser Form Control

Originally published at NoLongerSet.com

]]> <![CDATA[How to Set the Background Color of the Microsoft Access Application Window with VBA]]> https://medium.com/@NoLongerSet/how-to-set-the-background-color-of-the-microsoft-access-application-window-with-vba-87eb4db926a0?source=rss-78acf5965d4c------2 https://medium.com/p/87eb4db926a0 Sat, 23 Dec 2023 04:33:27 GMT 2023-12-23T04:33:27.674Z A series of Windows API calls will “repaint” the Microsoft Access canvas with the color of your choice. It is a bit rough around the edges, though…

By Mike Wolfe (connect on Twitter: @NoLongerSet)

Several years ago, I had a client ask me to change the application background color from its default gray.

As I recall, the application included a feature to switch the data source between current data and read-only archived data. She wanted the application background to change when viewing the archive data. To be clear, she was not asking to change the background color of the forms, but of the Access application window itself.

I spent more time than I care to admit trying and failing to make this work.

I searched online for a solution, but I came up empty-handed.

Many years later–with a deeper understanding of Windows API programming and the help of ChatGPT–I managed to write the surprisingly simple subroutine that eluded me back then: SetCanvasBgColor().

The Access Canvas

Known to some as the MDI (multi-document interface) client area, the Access canvas is the space that surrounds forms and reports within the Access window.

GetInnerAccessHwnd(): Retrieve the Window Handle to the Microsoft Access Canvas

This function returns the window handle to the Microsoft Access “canvas”, the inner portion of the application window where forms and reports are drawn.

No Longer SetMike Wolfe

It’s the area in teal in the screenshots below:

In fact, I used the SetCanvasBgColor() function to create the effect in these screenshots.

The Approach

The SetCanvasBgColor() function leverages the Windows API to interact with the Access application at a level deeper than what's typically exposed through VBA.

By obtaining the window handle of the Access canvas, we can directly manipulate its properties. The function uses a series of API calls to create a solid brush with the desired color and then fills the canvas area with that color.

It’s a clever workaround to an otherwise static aspect of Access’s UI.

The Algorithm

Here’s a breakdown of the SetCanvasBgColor() function in plain English:

  1. Obtain the Canvas Handle: Using the GetInnerAccessHwnd() function, we retrieve the handle to the Access canvas, which is the drawable area minus any docked elements like menus or toolbars.
  2. Get the Device Context: With the canvas handle, we call GetDC() to get the device context, which is necessary for any drawing operations.
  3. Create the Brush: We invoke CreateSolidBrush() with the color passed to the function to create a brush of the desired color.
  4. Determine the Area to Fill: The GetCanvas() function is called to get the coordinates of the canvas area.
  5. Fill the Area: We use FillRect() to fill the canvas area with the solid brush created earlier.
  6. Clean Up: Finally, we release the device context with ReleaseDC() to avoid resource leaks.

The Function

Here is the SetCanvasBgColor() function on its own without its required dependencies:

Sub SetCanvasBgColor(RgbColor As Long)
    Dim hWnd As LongPtr
    hWnd = GetInnerAccessHwnd

    Dim hdc As LongPtr
    hdc = GetDC(hWnd)
       
    Dim hBrush As LongPtr
    hBrush = CreateSolidBrush(RgbColor)
    
    Dim Rectangle As Rect
    Rectangle = GetCanvas
    
    FillRect hdc, Rectangle, hBrush

    ReleaseDC hWnd, hdc
End Sub

The Full Code

The code below includes required helper functions that I’ve written about in the past:

Option Compare Database
Option Explicit

Private Type Rect
    Left As Long
    Top As Long
    Right As Long
    Bottom As Long
End Type

' --== GetInnerAccessHwnd() declarations ==--
Private Declare PtrSafe Function apiFindWindowEx _
    Lib "user32" Alias "FindWindowExA" (ByVal hWnd1 As LongPtr, _
                                        ByVal hWnd2 As LongPtr, _
                                        ByVal lpsz1 As String, _
                                        ByVal lpsz2 As String) As LongPtr

Private Declare PtrSafe Function apiGetParent _
    Lib "user32" Alias "GetParent" (ByVal hWnd As LongPtr) As LongPtr


' --== GetCanvas() declarations ==--
Private Declare PtrSafe Function apiGetClientRect _
    Lib "user32" Alias "GetClientRect" (ByVal hWnd As LongPtr, _
                                        lpRect As Rect) As Long


' --== SetCanvasBgColor() declarations ==--
Private Declare PtrSafe Function GetDC _
    Lib "user32" (ByVal hWnd As LongPtr) As LongPtr

Private Declare PtrSafe Function CreateSolidBrush _
    Lib "gdi32" (ByVal crColor As Long) As LongPtr
    
Private Declare PtrSafe Function FillRect _
    Lib "user32" (ByVal hdc As LongPtr, _
                  lpRect As Rect, _
                  ByVal hBrush As LongPtr) As Long
                  
Private Declare PtrSafe Function ReleaseDC _
    Lib "user32" (ByVal hWnd As LongPtr, _
                  ByVal hdc As LongPtr) As Long


' ----------------------------------------------------------------
' Procedure : SetCanvasBgColor
' Date      : 12/12/2023
' Author    : Mike Wolfe
' Source    : https://nolongerset.com/setcanvasbgcolor/
' Purpose   : Sets the background color of the Microsoft Access canvas.
' Notes     - Background color reverts to default whenever a form
'               or report is closed or moved on the screen.
'           - Thus, this must be called in every form and report's
'               unload and resize events (and even that is not enough
'               because there is no form or report "move" event) OR
'               it must be called on a Timer (which presents its own
'               set of problems).
'           - Use the RGB() function to create the value to be passed
'               in the RgbColor argument.
' Sample Usage (e.g., in hidden global form):
'
'   Private Sub Form_Timer()
'       SetCanvasBgColor RGB(255, 0, 0)   'Set canvas background to Red
'   End Sub
' ----------------------------------------------------------------
Sub SetCanvasBgColor(RgbColor As Long)
    Dim hWnd As LongPtr
    hWnd = GetInnerAccessHwnd

    ' Get the device context
    Dim hdc As LongPtr
    hdc = GetDC(hWnd)
       
    ' Create a solid brush
    Dim hBrush As LongPtr
    hBrush = CreateSolidBrush(RgbColor)
    
    ' Get the area to fill
    Dim Rectangle As Rect
    Rectangle = GetCanvas
    
    ' Fill the rectangle area with the brush
    FillRect hdc, Rectangle, hBrush

    ' Release the device context
    ReleaseDC hWnd, hdc
End Sub



'---------------------------------------------------------------------------------------
' Procedure : GetInnerAccessHwnd
' Date      : 11/26/2014 - 12/12/2023
' Author    : Mike Wolfe
' Source    : https://nolongerset.com/getinneraccesshwnd/
' Purpose   : Gets the window handle of the Access "canvas".
' Notes     - We don't use hWndAccessApp here because that's the window handle for the
'               full application; what we really want is the handle for the "inner container";
'               i.e., the Access window minus the docked menus, docked toolbars, and status bar
'---------------------------------------------------------------------------------------
'
Function GetInnerAccessHwnd(Optional ByVal ChildHWnd As LongPtr = 0) As LongPtr
    
    GetInnerAccessHwnd = apiFindWindowEx(hWndAccessApp, ByVal 0&, "MDIClient", vbNullString)
    If GetInnerAccessHwnd <> 0 Then Exit Function

    On Error Resume Next
    If ChildHWnd = 0 Then ChildHWnd = Screen.ActiveForm.hWnd
    If ChildHWnd = 0 Then ChildHWnd = Screen.ActiveReport.hWnd
    If ChildHWnd = 0 Then ChildHWnd = Screen.ActiveDatasheet.hWnd
    GetInnerAccessHwnd = apiGetParent(ChildHWnd)
End Function

'---------------------------------------------------------------------------------------
' Procedure : GetCanvas
' Date      : 11/18/2011 - 12/14/2023
' Author    : Mike Wolfe
' Source    : https://nolongerset.com/getcanvas/
' Purpose   : Returns the Left, Top, Right, and Bottom coordinates of the Access canvas.
' Notes     - Convenience function normally used in conjunction with other API calls.
'---------------------------------------------------------------------------------------
'
Function GetCanvas(Optional ByVal ChildHWnd As LongPtr) As Rect
    Dim CanvasHwnd As LongPtr
    CanvasHwnd = GetInnerAccessHwnd(ChildHWnd)
    apiGetClientRect CanvasHwnd, GetCanvas
End Function

The code can be copied and pasted into a blank standard module for a fully-working solution that can be easily integrated into your projects.

Some Very Important Caveats

This function only sets a custom canvas background color; it does not keep a custom canvas background color. This has some important consequences.

Works Best With “Overlapping Windows”

Modern versions of Access provide two options for displaying document windows (i.e., forms and reports):

  • Overlapping Windows
  • Tabbed Documents

With “Tabbed Documents”, every open form and report completely covers the Access canvas. The only time you would see it is if there were no visible forms or reports at all (or every form/report was a popup). The code will still work with the “Tabbed Documents” option, it just won’t be of much practical value.

Access Redraws Its Canvas…A LOT

Every time Access “redraws” all or part of its canvas, the default background color is restored and you will have to call the

  • Resizing a form will reset the entire canvas back to its default color
  • Restoring a minimized form will reset the entire canvas back to its default color
  • Moving or closing a form will restore the default color of the canvas background for any portion of the canvas that the form was previously covering

There are three ways you can account for this:

  • Intercept the WM_PAINT message at the operating system level and call SetCanvasBgColor every time Access redraws the canvas (that approach is WAY beyond the scope of this article)
  • Add calls to SetCanvasBgColor in every form's Resize and Close events (besides requiring a lot of code, this approach also does not account for a user moving a form without resizing it, as there is no Form_Move() event you can handle)
  • Add a Timer event to an always-open form, such as a hidden global form and set the Timer to run at least once per second

Of these approaches, the Timer event is the easiest to implement, but it comes with a couple of major caveats of its own.

Timer Event Messes With the VBA Editor

Every time the Timer executes during development, VBA performs a just-in-time compile of the project. One of the side effects of compiling is that trailing whitespace is trimmed from all lines of code…including the one you may be editing. This happens regardless of the “Compile On Demand” and “Background Compile” settings in the VBE Options dialog.

So, if you take this approach, you’ll want to keep that form closed (or otherwise disable the Timer event) while you are writing code, or it will drive you absolutely crazy.

Frequent Timer Events Can Hurt Performance

For the best visual experience, you’ll want to set a pretty short timer (around 100ms or so). Unfortunately, the overhead of raising a VBA event that frequently could easily have a noticeable impact on your application’s performance.

In my original example, I would disable the timer and live with the default background color when the users were working with current data. Only when they switched to archived data would I enable the timer.

Sample Usage

Imagine you have a database application that needs to reflect your company’s branding, which includes a specific shade of blue as a background color. Here’s how you might use the SetCanvasBgColor() function in a hidden global form that's always open:

Private Sub Form_Timer()
    SetCanvasBgColor RGB(0, 122, 204)   ' Set canvas background to Brand Blue
End Sub

This form could have a timer event that periodically calls SetCanvasBgColor() to ensure that the canvas color remains consistent, even after other forms or reports are closed or moved. Be sure to set the form's Timer Interval property to a suitable number of milliseconds, such as 100 (to re-apply the background color every tenth of a second). To temporarily disable the timer, you can set the Timer Interval to zero.

One Final Note of Caution

Be sure to save your project often when working with this code, especially if you run it using a short timer.

Windows API calls in general will crash your application if you’re not careful, but API calls that deal with low-level drawing commands are especially finicky.

Furthermore, this code is brand new to me. Unlike many of the functions I post on this site–which have been in production use for a long time (and so have had lots of time to accumulate little bug fixes here and there), this is a very fresh function. There could easily be edge and corner cases that cause problems.

Your mileage may vary.

Acknowledgements

  • Portions of this article’s body generated with the help of ChatGPT

Originally published at NoLongerSet.com

]]> <![CDATA[Dropping `#If VBA7 Then` From API Declares]]> https://medium.com/@NoLongerSet/dropping-if-vba7-then-from-api-declares-52ebc42d8cd2?source=rss-78acf5965d4c------2 https://medium.com/p/52ebc42d8cd2 Fri, 22 Dec 2023 04:34:58 GMT 2023-12-22T04:34:58.153Z Plus, step-by-step instructions for restoring the `#If VBA7 Then` code construct if you still need to support Office 2007 or earlier.

By Mike Wolfe (connect on Twitter: @NoLongerSet)

It is time.

From this point forward, I no longer feel obligated to include the #If VBA7 Then construct in my Windows API calls.

In other words, code on my site that used to look like this…

#If VBA7 Then
    Private Declare PtrSafe Function apiGetParent _
        Lib "user32" Alias "GetParent" (ByVal hWnd As LongPtr) As LongPtr
#Else
    Private Declare Function apiGetParent _
        Lib "user32" Alias "GetParent" (ByVal hWnd As Long) As Long
#End If

…will now look like this…

Private Declare PtrSafe Function apiGetParent _
    Lib "user32" Alias "GetParent" (ByVal hWnd As LongPtr) As LongPtr

As I wrote in my 32-bit vs. 64-bit VBA Deep Dive article:

Now that we’ve had two perpetual VBA7-supported versions of Office reach end of life, I feel comfortable dropping support for Office 2007 and earlier in both my applications and my writing.

32-bit vs. 64-bit VBA: Deep Dive

A deep dive into the past, present, and future of the transition from 32-bit VBA to 64-bit VBA.

No Longer SetMike Wolfe

Here’s Why I’m Doing This Now

  • VBA7 has been available since Office 2010
  • Office 2007–the last version without VBA7–has been out of support since October 10, 2017
  • This makes it so I don’t have to choose between readability and compile-time type checks in my calling code (e.g., I can simply use As LongPtr instead of As Variant or #If VBA7 Then As LongPtr #Else As Long #End If)
  • It’s simple to adapt PtrSafe API declares to run in Office 2007 and earlier

That last point is the most important one for this blog.

I know all of my applications are running on Access 2010 or later. However, I am sure at least some of my readers have Access applications running on Access 2007 or earlier. If that’s you and you need to support those older versions of Access, read the next section for step-by-step instructions to convert my PtrSafe API declare lines to run in your version of Office.

Adapting API Declares to Run in Office 2007 and Earlier

As I lamented in my 32-bit vs. 64-bit VBA Deep Dive article, there is no simple algorithm to follow to convert 32-bit-only code to run under 64-bit VBA.

The main difficulty in moving from 32-bit-only API declares to 64-bit-compatible API declares was in identifying which Long parameters needed to be switched to LongPtr (i.e., which parameters represented memory pointers/object handles) and which should stay declared as Long (i.e., the arguments represented actual 32-bit signed integers). Figuring that out required using references such as the Win32_API.txt file, reading documentation for the API functions, or–in some extreme cases–finding and understanding the underlying C++ header files.

However, moving in the other direction is quite simple.

What’s more, if you follow the instructions below, your code will continue to run in 64-bit versions of VBA while also being backward-compatible with VBA6 versions of Office (2007 and earlier).

Step-by-Step Instructions

Here are the steps to migrate a VBA 7-only API declare to run in both 64-bit environments and Office versions 2007 and earlier (i.e., pre-VBA 7):

  1. Add the following line of code before your existing API declare: #If VBA7 Then
  2. Add the following line of code after your existing API declare: #Else
  3. Copy and paste your existing API declare to the line following the #Else
  4. Delete the keyword PtrSafe from the copied line
  5. Replace any instances of LongPtr with Long in the copied line
  6. Add the following line of code after the copied line: #End If

Here’s an example from a recent article:

Before

The code below works in both 32-bit and 64-bit environments in Office 2010 and later:

Private Declare PtrSafe Function apiGetParent _
    Lib "user32" Alias "GetParent" (ByVal hWnd As LongPtr) As LongPtr

After

The code below works in both 32-bit and 64-bit environments in Office 97 and later:

#If VBA7 Then
    Private Declare PtrSafe Function apiGetParent _
        Lib "user32" Alias "GetParent" (ByVal hWnd As LongPtr) As LongPtr
#Else
    Private Declare Function apiGetParent _
        Lib "user32" Alias "GetParent" (ByVal hWnd As Long) As Long
#End If

How Do You Know If You Need To Do This?

The PtrSafe keyword was introduced in VBA 7, which debuted in Office 2010.

If you are running Office 2007 or earlier, this keyword does not exist yet and you will get the following error when trying to compile code that includes the keyword:

Compile error:

Expected: Sub or Function

Why Does Adding #If VBA7 Then Fix My Code?

You may be wondering how adding the #If VBA7 Then line could make the compile error go away in these earlier versions of VBA.

How can a feature introduced in VBA7 (i.e., the VBA7 compiler constant), be recognized by earlier versions of the language? After all, isn't the original problem the fact that the PtrSafe keyword is not recognized by earlier versions?

The key difference is that PtrSafe is a language keyword while VBA7 is a compiler constant.

When VBA encounters a language keyword that it does not recognize, that triggers a compile error (technically, it’s a syntax error, since the keyword is not part of the language grammar).

However, when VBA encounters a compiler constant that it does not recognize, the compiler constant simply evaluates to False.

So, by introducing a compiler constant–VBA7–that evaluates to True in VBA 7 (and later versions, on the unlikely chance that a VBA 8 ever gets released), Microsoft provides a way for developers to "hide" new language features from older versions of the language.

Cover image generated with DALL-E-3

Originally published at NoLongerSet.com

]]> <![CDATA[FIXED: “You entered an expression that has no value.”]]> https://medium.com/@NoLongerSet/fixed-you-entered-an-expression-that-has-no-value-c9af420b9d61?source=rss-78acf5965d4c------2 https://medium.com/p/c9af420b9d61 Thu, 21 Dec 2023 04:58:26 GMT 2023-12-21T04:58:26.442Z “You entered an expression that has no value,” is a common Microsoft Access error message. Luckily, while the fix is not obvious, it is easy.

By Mike Wolfe (connect on Twitter: @NoLongerSet)

Have you ever opened a form or report after making a minor change to a text box’s Control Source property and been greeted with the following error message?

Run-time error ‘2427’:

You entered an expression that has no value.

The most likely reason for this error is that you’ve inadvertently created a circular reference in a text box’s Control Source.

MCVE: Minimal Complete Verifiable Example

The gold standard when trying to reproduce an error is to define a “minimal complete verifiable example” of the bug. Not all bugs lend themselves to an MCVE, but it should still be your goal as a developer to create one, if possible.

Here are the steps to generate an MCVE for this error message:

  1. Create a new blank database
  2. On the Create tab, click [Form Design]
  3. In the Form’s Record Source property enter MSysObjects (if necessary, press [Alt] + [Enter] to open the Property Sheet)
  4. On the Form Design tab, click [Add Existing Fields]
  5. Click and drag the DateCreate field from the Field List to the form’s Detail section
  6. Switch to Form View

At this point you should see the DateCreate text box displaying the value from the first row of the MSysObjects table. Since you just created the database, the DateCreate value should be today’s date:

So far, so good. Now, let’s break it.

Calling a Custom VBA Function

To generate the error message, we need to call a custom VBA function. For simplicity’s sake, we’ll use my Watch() function. It’s a debugging procedure that simply returns whatever value is passed to it.

'source: https://nolongerset.com/watch-this/
Function Watch(Val, Optional CalledFrom As String = "")
    'Debug.Assert Val <> "Value to watch for"
    'Debug.Print Val, CalledFrom
    Watch = Val
End Function
  1. Copy the above function and paste it into a new standard module
  2. Switch the form back to Design View
  3. Change the Control Source of the DateCreate text box from DateCreate to =Watch([DateCreate])
  4. Switch the form to Form View

You should get the following error message:

Run-time error '2427': You entered an expression that has no value.

What’s going on here?

Circular Reference

One of the annoying default behaviors of Access is that when you add a control to a form or report from the Field List window, it creates a text box whose Name and ControlSource are both set to the field name.

  • Name: DateCreate
  • Control Source: DateCreate

Everything is still OK at this point.

But what happens if we want to pass the field name to a custom VBA function?

  • Name: DateCreate
  • Control Source: =Watch([DateCreate])

The problem is that Microsoft Access automagically creates form object properties for every control and every field associated with the form. So, for our form, there is a DateCreate control and a DateCreate field. If a form has a control and field with the same name, the control property takes priority.

So, when the Access database engine’s expression service evaluates =Watch([DateCreate]), the reference to [DateCreate] resolves to the DateCreate control and not the DateCreate field. This results in a circular reference: the function is infinitely recursive.

Theoretically, the expression service evaluates this:

=Watch([DateCreate])

As this:

=Watch(Watch([DateCreate]))

And then as this:

=Watch(Watch(Watch([DateCreate])))

Ad infinitum (or at least until it runs out of stack space).

In reality, the expression service likely looks for this situation and flags it as invalid without actually performing the recursive calculation.

In fact, newer versions of Access bring this error to the user’s attention by flagging it in Design View:

Access also provides you with the two possible fixes:

  • Edit Control Name
  • Edit the Control’s Control Source Property

As well as showing you a “Help on This Error” option which brings you right to this page to explain what is going on.

Haha! Just kidding. Clicking on Help on This Error shows you this:

That darn network connection! Somehow, the internet works fine just before and just after I try to use the Access Help.

Fixing the Error

As the context-sensitive error-flagging tooltip shows, there are two approaches to fixing the error. Note that these fixes also apply to older versions of Access, including those that do not automatically flag the error in Form Design View.

Edit Control Name

With this approach, we change the control name so that it doesn’t conflict with the field name.

For example, we could change the name of the control from CreateDate to tbCreateDate.

By doing that, we give unique names to two form properties that previously shared the same name:

  • CreateDate: one of the fields in the form's Record Source
  • tbCreateDate: one of the text box controls on the form's Detail section

Personally, this is the approach I use.

In fact, I don’t even wait for these kinds of errors to pop up. I proactively change the name of every control as I add it to my form, especially if I use the Field List to create the control.

I don’t use Systems Hungarian in my code, but I have adopted a form of that naming convention for my form and report controls. I use the following prefixes for my controls:

  • tb: Text box
  • cb: Combo box
  • lb: List box
  • lbl: Label
  • chk: Check box
  • btn: Command Button
  • rect: Rectangle
  • img: Image
  • og: Option Group
  • ob: Option Button
  • tc: Tab Control
  • sf: Sub Form
  • sr: Sub Report
  • tog: Toggle Button
  • web: Legacy Web Browser Control
  • edge: Modern Edge-based Browser Control
  • pb: Page Break
  • line: Line
  • ax: ActiveX

Edit the Control’s Control Source Property

Honestly, this approach only makes sense if you’ve got a typo in your control source or you really are referring to the wrong thing. In the vast majority of cases, the best solution will be to simply rename the control as described above.

Feature Request

I would love to see the option to define control name prefixes by control type. This would have to be a user-configurable option, since different developers use different naming conventions (e.g., cmd is another common prefix for command buttons). This feature could be implemented in one of two ways:

As an Access Option

Go to File > Options > Object Designers > Form/Report design view.

Under the “[_] Always use event procedures” option, add another checkbox that is unchecked by default, that says:

[_] Use control name prefixes [Define…]

The [Define…] button would be disabled unless the box was checked. Clicking on the enabled [Define…] button would open a form with a two-column list. The first column would have a header of “Prefix” and the second column would have a header of “Control Type.” “Prefix” would be a column of empty text boxes where the user could define prefixes for all the form and report control types which would be listed in the second column. Essentially it would look like my unordered list under the “Edit Control Name” section heading above.

As a Default Control Property

The other way to implement this feature would be to expose the Name property in the default control view of the Property Sheet.

For example, here’s what the “Other” tab looks like for an existing Label control:

And here’s what the “Other” tab looks like when we click on the Label control button in the ribbon’s Controls group and the Default Label control is active. The properties listed below are the only ones under the “Other” tab that can be set for a label control. “Name”, “Help Context Id”, and “Tag” cannot be given default values.

I propose that we add either a “Name Prefix” property (which would be a clearer name, but could be a problem because it’s not an existing control property) or expose the existing control “Name” property and treat its contents as though it were a “name prefix” property.

Official Feature Request on the Feedback Portal

I’ll be honest, I’m completely jaded by the whole feature request situation since my top-ranked feature request simply disappeared as part of the site’s automated cleanup process. (It appears Microsoft added it back as a new request about a year after they unceremoniously deleted it, but it lost an awful lot of ground over that time.)

If someone likes this idea enough to post it on the feedback site, I will gladly upvote it (throw a link in the comments below). As for me, I won’t be wasting the time to do it myself.

Originally published at NoLongerSet.com

]]> <![CDATA[Poe: My Tool of Choice for Exploring the World of LLMs]]> https://medium.com/@NoLongerSet/poe-my-tool-of-choice-for-exploring-the-world-of-llms-35dc40dabe49?source=rss-78acf5965d4c------2 https://medium.com/p/35dc40dabe49 Wed, 20 Dec 2023 05:33:39 GMT 2023-12-20T05:33:39.911Z With so many new and exciting LLMs and AI image generators, how do you pick just one? What if you didn’t have to?

By Mike Wolfe (connect on Twitter: @NoLongerSet)

Over the past thirteen months–since the public release of ChatGPT on November 30, 2022–the AI ecosystem has exploded.

It seems like almost every day we have a new or updated LLM:

  • ChatGPT 3.5
  • ChatGPT 4
  • Claude-instant-100k
  • Claude-2–100k
  • Llama-2–70b
  • Mixtral-8x-7B
  • Gemini-Pro

Not to mention some popular image generation tools:

  • DALL-E-2
  • DALL-E-3
  • Playground-v2
  • Stable-Diffusion-XL

As vendors compete in the AI arms race, many of these tools are free to use–at least for preview purposes. To gain access to the newest and most powerful tools (or to avoid restrictive usage caps), you generally need to pay up.

With all these options, though, how do you know which one to invest in?

Option E. All of the Above

After playing around with the free version of ChatGPT for awhile, I realized that these tools were the future and that I needed to invest in learning how to use them to avoid falling behind.

As companies raced to outdo each other, I didn’t want to bet on the wrong horse.

And then I learned about Poe.

The poe.com site itself doesn’t include much information about itself, so here’s a summary of the Poe service from Wikipedia:

Poe (Platform for Open Exploration) is a service developed by Quora and launched in December 2022. It allows users to ask questions and obtain answers from a range of AI bots built on top of large language models (LLMs), including those from ChatGPT developer OpenAI, and other companies like Anthropic. It also has a subscription which allows users unlimited use for lightweight chatbot applications, such like ChatGPT and provides access, with certain limitations, to more complex and advanced artificial intelligence models such as like GPT-4 and Claude2.

In other words, a subscription to Poe gives you access to ALL the most popular LLMs and image generators, including all the ones I listed above.

Features of Poe

Here are the top reasons I use Poe:

Cover image generated with DALL-E-3 (via Poe)

Originally published at NoLongerSet.com

]]> <![CDATA[“AI Will Take My Job”: A Self-Fulfilling Prophecy]]> https://medium.com/@NoLongerSet/ai-will-take-my-job-a-self-fulfilling-prophecy-523f0b33fb30?source=rss-78acf5965d4c------2 https://medium.com/p/523f0b33fb30 Tue, 19 Dec 2023 05:21:30 GMT 2023-12-19T05:21:30.859Z Whether you think AI is coming to *take* your job… Or you think AI will help you *be more productive* at your job… You’re probably right.

By Mike Wolfe (connect on Twitter: @NoLongerSet)

Here’s an old joke you’ve likely heard before in one form or another:

A deeply religious man lived by the river. One day, heavy rain fell and the river started rising. As the water levels increased, a neighbor in a canoe paddled by and said to the man, “Quick, get in my canoe, the waters are rising!”

The man replied, “No, thank you. I have faith that God will save me.”

The water kept rising and now entered his first floor. A rescue team in a motorboat came by and one of the rescuers said, “Hurry up, get in! The water is still rising!”

Again, the man declined, “No need, I am waiting for God to save me.”

Eventually, the man had to climb up to his roof as the water level rose even higher. A helicopter flew over, and the pilot dropped down a ladder, shouting down to the man, “Grab the ladder, this is your last chance!”

For the third time, the man refused, shouting back, “I have faith! God will save me!”

Not long after, the waters overcame the house and the man drowned. Upon reaching heaven, the man had the chance to speak with God. He asked, “God, I had unwavering faith in you. Why did you not come to save me?”

And God replied, “What do you mean? I sent you a canoe, a motorboat, and a helicopter!”

I’ve been thinking about this joke a lot lately as I’ve begun to notice that Access developers (and tech workers more generally) seem to fall into two main camps:

  • Those who think AI is coming for our jobs and therefore resent it
  • Those who think AI is the next step forward in productivity and therefore embrace it

My concern is that both camps could be correct about themselves.

Let’s explore.

Embracing AI in Development: A Tale of Two Choices

In the rapidly evolving world of software development, professionals stand at a crossroads shaped by the advent of Artificial Intelligence (AI).

As reflected in the opening parable, developers are currently presented with a defining moment in their professional journey. The unfolding narrative of AI in the tech industry isn’t just about new tools and technologies; it’s about recognizing the significance of adaptation and the willingness to leverage the resources at our disposal. Just as the man in the story faced a crucial decision amidst the rising floodwaters, developers too must decide their stance on the integration of AI into their work.

In a similar vein, today’s developers are faced with a choice that could determine the trajectory of their careers: to embrace AI or to reject it.

The New Landscape of AI

AI technologies, like ChatGPT, are the canoes, motorboats, and helicopters of our era.

They represent the tools and opportunities extended to developers to navigate the rising waters of industry demand and technological advancement. AI has the potential to automate tedious tasks, optimize workflows, and provide insights that were previously unattainable, thereby enhancing the productivity and creativity of those who wield it.

The Choice to Embrace

Developers who choose to embrace AI open themselves up to a world of possibilities.

These individuals will not only secure their relevance in the job market but also gain access to new and exciting opportunities. By leveraging AI, mundane aspects of programming can be streamlined, allowing developers to focus on more complex and innovative aspects of their projects.

The developers who see AI as a partner rather than a replacement are the ones who will become more productive, more competitive, and ultimately, thrive in the AI economy.

The Choice to Eschew

Conversely, those who choose to eschew AI, perhaps out of fear or a belief that it represents an existential threat to their jobs, risk falling behind.

By ignoring the ‘rescue boats’ of AI, these developers inadvertently decrease their productivity and competitive edge. In the fast-paced world of technology, stagnation can be akin to regression.

The refusal to adapt and the insistence on maintaining traditional methods in a transforming field can lead to obsolescence.

The Self-Fulfilling Prophecy

The story of the flood victim who shunned help is not just a cautionary tale about faith and rescue; it’s a lesson in the self-fulfilling nature of our beliefs and choices. In the context of AI and development, the prophecy is twofold:

If you believe that AI is the end of your job and refuse to engage with it, you may very well find yourself out of work. Not because AI has usurped your position, but because the industry has moved toward those who can complement their skills with AI’s capabilities.

If you believe that AI is a tool that can enhance your productivity and open new doors, you will be right. By incorporating AI into your skillset, you will find that it amplifies your abilities, makes you a more valuable asset to any team, and positions you at the forefront of innovation.

Conclusion

The moral for developers in this AI-driven age is clear: the future belongs to those who recognize and seize the assistance and opportunities AI provides.

Embracing AI doesn’t mean the end of your job; it means the enhancement of your job. It’s an invitation to grow, to improve, and to be part of the exciting evolution of technology.

As the waters of change continue to rise, the choice each developer makes — to embrace the rescue boats of AI or to refuse them — will shape their path forward in profound ways.

Other Views

A few other Access developers have explored the role of AI and how it might shape the future of software development.

Richard Rost

Recently reawarded Access MVP Richard Rost seems to be in the same metaphorical boat as me. He explored this topic recently on his YouTube channel:

Rick Hanson (Pharos Technology)

Dr. Richard Hanson took a slightly different approach, testing ChatGPT to see how close it is to taking the job of an Access developer today (spoiler alert: your jobs are safe for now):

Daniel Pineault

Longtime Access MVP Daniel Pineault is not a fan. He takes particular issue with the copyright implications of LLMs like ChatGPT:

AI, ChatGPT And This Blog | DEVelopers HUT

Why, for now, you will not see any AI/ChatGPT content on my blog or any other places I contribute,

DEVelopers HUTDaniel Pineault

Karl Donaubauer

Twenty-five-year (!) Access MVP Karl Donaubauer takes a more nuanced approach. Several months ago, Karl signed onto the open letter calling for a six-month pause of “giant AI experiments.” However, he announced his signing of that letter in the same article in which he introduced the first commercial AI add-in developed for Microsoft Access, acknowledging that it would be naive to expect AI research to actually pause in any meaningful way.

The first AI Add-In for Access

AI here, there, anywhere. A third-party vendor offers the first comprehensive AI integration tool for Access.

AccessForeverKarl Donaubauer

Acknowledgements

  • Portions of this article’s body generated with the help of ChatGPT (because of course 😉)
  • Cover image generated with DALL-E-3

Originally published at NoLongerSet.com

]]> <![CDATA[twinBASIC Update: December 17, 2023]]> https://medium.com/@NoLongerSet/twinbasic-update-december-17-2023-81b5b21a276c?source=rss-78acf5965d4c------2 https://medium.com/p/81b5b21a276c Sun, 17 Dec 2023 22:46:03 GMT 2023-12-17T22:46:03.567Z Highlights include a new twinBASIC project to allow easy input filtering of text boxes and the renaming of the tbShellLib project to reflect its expanded scope.

By Mike Wolfe (connect on Twitter: @NoLongerSet)

On April 23, 2021, I helped Wayne Phillips introduce the world to twinBASIC at the Access DevCon Vienna conference. I boldly predicted that twinBASIC (along with the Monaco editor) would replace VBA and its outdated development environment by 2025. With that goal in mind, this weekly update is my attempt to keep the project fresh in the minds of the VBA development community.

Every Sunday, I will be providing updates on the status of the project, linking to new articles discussing twinBASIC, and generally trying to increase engagement with the project. If you come across items that should be included here, tweet me @NoLongerSet or email me at mike at nolongerset dot com.

Here are some links to get involved with the project:

Highlights

Weekly Teaser

Another week goes by without a new release of twinBASIC.

The extended delay has not gone unnoticed to users like fafalone:

it’s now been one full month since the last release. seems to be the longest gap ever. i know there’s huge improvements on the way but damn this is a rough wait 😵

It would seem the delay is not due to a lack of interest from the development team, as Wayne responded, simply:

Trust me, it’ll be worth the wait.

Discord Chat Summary

* Auto-generated via Claude-2–100k on poe.com

Here is a summary of the key points from the General channel transcript for twinBASIC development over the past week:

  • There was extensive discussion around potential funding models to support continued development of twinBASIC, with estimates around needing 100k Euros per year. Crowdfunding from the community was proposed as one option.
  • Work continues on the next major twinBASIC release, with the longest gap ever between releases now at 1 month. Hints were given that it will be worth the wait.
  • Features like PNG transparency in PictureBox, LLVM optimizations, and enums with non-Long types were discussed. The twinBASIC team is looking at implementing improvements in these areas.
  • Community members continue finding obscure bugs and edge cases, reporting them to help improve stability. The team acknowledges the next release will take time to stabilize.
  • Conversations around potentially open sourcing parts of the project continued, with suggestions like starting with the IDE source code to allow more community contributions.
  • Microsoft’s own specifications around things like COM enums appear to contradict how VB6 actually implemented them. The team is weighing being strictly standards compliant vs maximizing capabilities.

Overall, progress continues towards the next major twinBASIC release that will bring many new capabilities, though it is taking longer than usual. The team remains committed to supporting the community and discussing ways to sustain project development long-term.

Around the Web

LimitInputEdit: Easy Input Filtering for TextBoxes

Another new twinBASIC project from fafalone is now available on GitHub:

This is an updated, x64 compatible version of my VB6 demo of the shell32.dll API SHLimitInputEditWithFlags, an API entirely undocumented either by Microsoft or 3rd parties until my project. There are three versions of the project in this repository, LimitInputEditWithFlags.twinproj, a full twinBASIC version that uses Return and Handles syntax etc, and a universal compatibility version (VB6, VBA6, VBA7 32bit, VBA7 64bit, twinBASIC 32bit, twinBASIC 64bit) in both VB6 and twinBASIC form with identical code.

tbShellLib Being Rebranded as WinDevLib

fafalone will be renaming his tbShellLib project to WinDevLib to better reflect the expanded scope of the project:

I’m planning on renaming this project to WinDevLib — Windows Development Library for twinBASIC, to better reflect the purpose, since as it’s grown the original mission of shell programming has become only a part of it; the largest single part, but not even close to a majority anymore. Also a couple other significant changes, including redefining LARGE_INTEGER to QuadPart As LongLong instead of high/low Longs... this in accordance with how it's treated by the Windows API--- the C definition is a Union between both options, but this means it always triggers 8-byte alignment rules. Problems from not having that were rare in 32bit, but so common in 64bit it was previously relegated to legacy compatibility and all internal defs used QLARGE_INTEGER instead. But that's not a real Windows type.

I was hoping to hold off on this change until tB had union support, so the 8 byte alignment issue could be resolved without breaking compatibility with low/high Long usage. But with that pretty much ruled out as a 1.0 feature recently, I feel it's important to go ahead and make this change (and the name change) now before tB hits 1.0, since once tB is a stable product I think the same applies to major community projects around in beta.

So LARGE_INTEGER will now have .QuadPart only, and all QLARGE_INTEGER will be replaced with LARGE_INTEGER. Less impactful but still of note, SendMessage and PostMessage will now follow the same API standards as the rest of the project, pointing to SendMessageW and PostMessageW respectively, and using DeclareWide. This won't impact >99% of usage, since using a String with DeclareWide is the same plain usage without conversion it's always been, but it's still worth noting. Both this and the other change are noted in [ Description ] attributes.

The existing versioning will be retained; the initial release will be 7.0.272. Compiler constants will be updated; e.g. WINDEVLIB_LITE instead of TB_SHELLLIB_LITE.

Let me know if there's any thoughts, comments, suggestions, questions, objections, or as always, coverage requests; it will still be a couple days before the new version is initially released.

Changelog

Here are the updates from the past week. You can also find this information by visiting the GitHub twinBASIC Releases page.

Releases · WaynePhillipsEA/twinbasic

Contribute to WaynePhillipsEA/twinbasic development by creating an account on GitHub.

GitHubWaynePhillipsEA

No new releases this week.

Originally published at NoLongerSet.com

]]> <![CDATA[Week in Review: December 16, 2023]]> https://medium.com/@NoLongerSet/week-in-review-december-16-2023-9a21b9e256cf?source=rss-78acf5965d4c------2 https://medium.com/p/9a21b9e256cf Sun, 17 Dec 2023 02:46:58 GMT 2023-12-17T02:46:58.820Z Highlights include my recent talk on using classes with import/export specs, many 64-bit VBA guides, and a new release of Adam Waller’s version control add-in.

By Mike Wolfe (connect on Twitter: @NoLongerSet)

Just Published

This section includes videos, articles, and interesting discussions from the past 7 days.

Articles

Videos‌

Select Open Source Projects: New Releases

New to Me

This section includes content I discovered this week that has been around for awhile.

Nothing new this week.

Upcoming Access User Group Events

NOTE: Only English-language user group meetings with scheduled guest speakers or topics are listed. For a complete list of upcoming events, visit the Access User Group event calendar.

  • January 3, 2024: Ramachandran (A.P.R.) Pillai — Streamlining the Form Module Code in the standalone Class Module
  • January 4, 2024: Kent Gorrell — The Power of Sub classes in Access VBA
  • February 7, 2024: Carlos Quintero — Features of MZ-Tools to make you more productive with VBA
  • March 6, 2024: Thomas Möller — Better Access Charts in the new Edge Browser Control
  • April 3, 2024: Dale Fye — Working with Command Bars and the Access Shortcut Tool
  • April 18–19, 2024: Access DevCon Vienna — (Online in Microsoft Teams) Agenda to be announced
  • May 1, 2024: Colin Riddington — View & Edit Import/Export (IMEX) Data Task Specifications

‌

Access Roadmap

There were NO CHANGES to the roadmap between the last Week in Review (2023–12–09) and this one (2023–12–16).

The development priorities were last updated at the German-language AEK conference on October 14, 2023.

Listed below is a snapshot of the official Access Roadmap.

“In Development”, “Rolling Out”, and “Launched” are Microsoft terms that I pulled straight from the public roadmap.

“Development Priorities” do not appear on the Access Roadmap. Instead, they get updated from time to time in official Access blog posts or Access engineering team presentations. I’ll include a link to the source of the current development priorities as they get updated.

Development Priorities

The items listed below reflect Microsoft’s order of priority and were published in the following article, Microsoft’s Plans for Access in the Next 6 Months.

The items are listed in priority order according to Principal Engineering Manager Dale Rector. The “Expected Benefit” of each feature is shown in italics after the description of the feature itself.

New priorities added since the previous set of priorities are shown in bold below. Dropped priorities are struck through.

  1. Continued Focus on Monthly Issue Fixes: (Monthly Issue Fix Blog) Improved product quality and reliability
  2. Access becomes Large Address Aware: Removal of key customer error issue
  3. Dataverse export improvements: Make it easier and faster for admins to migrate their data to Dataverse
  4. Large monitor support for forms: Improved support of Access on the latest hardware
  5. Modern Chart Improvements: Expanded support for the most popular chart types and options
  6. SQL Editor Improvements: Significantly improved SQL query editing experience
  7. Inconsistent Database Error Fix

Special thanks to Karl Donaubauer for posting the updated priorities at AccessForever.org.

In Development

Rolling Out

None.

Launched

  • APR 2023: Modern Web Browser Control
  • MAR 2023: New Modern Web Browser Form Control

Originally published at NoLongerSet.com

]]>