Skip to content

Enhanced GetUPSVar to support variable name arrays #215

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: dev-2.3
Choose a base branch
from

Conversation

leongurman
Copy link

  • Added overload accepting String() array parameter
  • Tries each variable sequentially until one succeeds
  • Maintains backward compatibility with single variable calls
  • Returns first successful result or fallback if all fail

Usage: GetUPSVar({"ups.mfr", "device.mfr"}, "Unknown")

- Added overload accepting String() array parameter
- Tries each variable sequentially until one succeeds
- Maintains backward compatibility with single variable calls
- Returns first successful result or fallback if all fail

Usage: GetUPSVar({"ups.mfr", "device.mfr"}, "Unknown")
@gbakeman
Copy link
Contributor

gbakeman commented Aug 1, 2025

This was a very unexpected but appreciated pull request, thank you! Do you plan to make more contributions to the WinNUT core code? I've been behind on a lot of things lately, so I want to take some time and sit down with this to take a proper look. One thing I want to say right off the bat is the idea of using an array of fallback variables for a single query, to maximize the chances of getting what you want.

One thing in particular that I've struggled with is how WinNUT handles invalid NUT variables (see pull request here). It used to be that it would automatically substitute in default-y or nominal -looking values for important information like battery status and other electrical indicators. So I've been on this crusade of removing default-return behavior from code in WinNUT, preferring instead to use some combination of exceptions and/or RaiseEvents because this is WinForms after all 😅. I'm not sure how I feel about returning a default value, maybe you can help me with setting up WinNUT to handle errors.

I also want to eventually generalize and extract the operational code from WinNUT-Client into a separate library (which is in C#), work which I was doing here. I think we can achieve a true OOP structure, with variables represented with individual objects that handle errors internally and accurately communicate their status to any client code.

Anyways, there's still a lot of work to do. I currently have an issue open here, which is like a summary of everything I want to do on the variable-side of the code. I'll definitely add this PR to the list and look into integrating it. The last thing I remember working on was the build system, so I'm way out in Powershell land ATM and may not be able to get to this until I can get that, and a translation committed, and maybe the installation/distribution system upgraded as well. 🙃Sorry, there's a lot going on! But thank you again for taking the time to do this and for making this contribution. I'm curious to hear what you think about everything I've said here and what your plans are for this project.

@gbakeman gbakeman added the enhancement New feature or request label Aug 1, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants