ANN: vuFileTools update with new modern password UI

I have released a new vuFileTools update, and it is a free update for all Version 5 customers.

This release includes two useful improvements.

First, vuFileTime and vuFileDate have been updated with a larger internal buffer so they can handle much longer file paths back to the source file. That makes them better suited for today’s deeper folder structures, longer filenames, and more complex path situations.

Second, vuFileTools now includes new password functions that let you upgrade a standard Clarion entry control with the password mask enabled into a more modern-looking UI with very little effort.


With a single function call, you can enhance your existing masked entry control to support cue text and a built-in eye button that toggles password visibility on and off. The result is a cleaner, more professional login experience that also helps reduce over-the-shoulder password exposure.

Best of all, this is done using the native Clarion entry control with the password mask. Your existing embeds and logic continue to work because underneath it all, it is still the real Clarion control.

For anyone interested, the help and example code are here:

The template now includes a secure login window that you can import into your application by way of a utility template. Or, if you prefer, you can simply use the function in your existing login screen and modernize it in place.

If you are already a Version 5 vuFileTools customer, this update is free. Just download it again using the same information you received with your order.

If you do not already own vuFileTools, details are here:

https://clarionproseries.com/html/vufiletools.html

Charles

How long is that because people can bolt in .net to win32 apps?

The maximum path of 32,767 characters is approximate, because the "\?" prefix may be expanded to a longer string by the system at run time, and this expansion applies to the total length.

The old internal limitation was 128 characters, caused by the legacy OPENFILE/OFSTRUCT path handling that those functions originally used.

In the update, I changed both vuFileTime() and vuFileDate() to use CreateFile() directly instead, so they are no longer limited by that old 128-character internal buffer.

That does not automatically mean a guaranteed 32,767-character path in every Clarion app, because Windows long-path behavior still depends on the application, manifesting, and how the path is being passed in. But it does remove the old fixed vuFileTools internal limit that was causing the failure.

The Maximum Path is 260 for an application that uses the ANSI “A” Windows API, as has been discussed here previously link below.

Clarion 1 to 12 all use ANSI Windows. Until some release of 12+ changes things there is no other option.

So whats the limit of the vuFileTools then?

And by your own admission

So to avoid using a programming tool for deprecated api’s, devs can use ‘W’ widestring aka unicode and .Net in their apps and .net works on file paths upto 32,767 characters in length.

Exactly Carl,

The old limitation was not a separate hard-coded vuFileTools restriction. It came from the older Windows API method originally used in those functions. The legacy OPENFILE() / OFSTRUCT approach effectively imposed a 128-character path limit.

I updated both functions to use CreateFile() instead, so that old 128-character internal limit is gone. But vuFileTools still lives inside the real-world limits of Clarion and the Win32 calling environment, so this should be understood as removing the old vuFileTools-side bottleneck rather than claiming unlimited long-path support.