Vectric Quick Data_Ver_1.0

[ira]

On my machine 3 of them look like this. The Hot keys starts big enough that it makes sense:

[Adrian]

That looks like you've got quite a hefty scale set in your Windows display settings.

[sharkcutup]

That looks like you've got quite a hefty scale set in your Windows display settings.

Yup, he does --- 4k 16" (3840x2400) set to 200%

Sharkcutup

[ira]

Another suggestion. In the Hot key list you have occasional headings that for me get lost in the noise, would bumping their size a couple of points and getting rid of the word wrapping for those lines help them stand out better.

And lastly, looking at the code, I see you try to save and restore the window sizes using RegistryRead and Write but at least here, it does not seem to work. I can tell the Write worked because the entries in the registry are populated with the expected 1250 x 850 and 1250 x 375. It does respect changes in the registry as I changed them to 1250 x 1200 and 1250 x 575 and you changed them right back to 850 and 375 when you hit the first RegistryWrite() in the code. I have 2 suggestions. You're going through a lot of effort to change from integers to strings and back again when you could just save two integers for each window. I assume the first time you call Write before a window is opened, You might also want to rename RegistryWrite() to RegistryInit() and only call it once at the start of the program.

I fixed the overwrite problem by replacing most of the calls to RegistryWrite() with this:

Code: Select all

function RegistrySaveWindow(Name, data)
    local RegistrySave = Registry(Project.GadgetTitle)
    RegistrySave:SetString(Name, data)
    return true
end

and the all calls to RegistryWrite() with something like this:

Code: Select all

  RegistrySaveWindow("DialogWindow.HotKeysXY", DialogWindow.HotKeysXY)

And after all that, I found that the calls to dialog.WindowWidth and dialog.WindowHeight always return the initial value so the effort to save and restore window sizes sees to be for naught. But this is the fist time I've ever tried to write LUA, so who knows what I might have done wrong.

[ira]

I do. There must be a way to query Windows to find out the current screen size and resolution to make more intelligent choices when sizing windows but I don't know enough about LUA to know if there is a way. I'm used to .NET and then it's easy.

[sharkcutup]

Ira thank you for your input and thoughts! Terrific feedback!

I am not at the computer right now but as soon as I am I will definitely looked into those items.

Thank you,
Sharkcutup

[sharkcutup]

Another suggestion. In the Hot key list you have occasional headings that for me get lost in the noise, would bumping their size a couple of points and getting rid of the word wrapping for those lines help them stand out better.

And lastly, looking at the code, I see you try to save and restore the window sizes using RegistryRead and Write but at least here, it does not seem to work. I can tell the Write worked because the entries in the registry are populated with the expected 1250 x 850 and 1250 x 375. It does respect changes in the registry as I changed them to 1250 x 1200 and 1250 x 575 and you changed them right back to 850 and 375 when you hit the first RegistryWrite() in the code. I have 2 suggestions. You're going through a lot of effort to change from integers to strings and back again when you could just save two integers for each window. I assume the first time you call Write before a window is opened, You might also want to rename RegistryWrite() to RegistryInit() and only call it once at the start of the program.

I fixed the overwrite problem by replacing most of the calls to RegistryWrite() with this:

Code: Select all

function RegistrySaveWindow(Name, data)
    local RegistrySave = Registry(Project.GadgetTitle)
    RegistrySave:SetString(Name, data)
    return true
end

and the all calls to RegistryWrite() with something like this:

Code: Select all

  RegistrySaveWindow("DialogWindow.HotKeysXY", DialogWindow.HotKeysXY)

And after all that, I found that the calls to dialog.WindowWidth and dialog.WindowHeight always return the initial value so the effort to save and restore window sizes sees to be for naught. But this is the fist time I've ever tried to write LUA, so who knows what I might have done wrong.

Check out this Version for your Setup --- Is it any better?

_Vectric Quick Data_Ver_1.5.vgadget

(246.41 KiB) Downloaded 7 times

Sharkcutup

[ira]

It seems better. It leaves alone my registry changes so the windows are a reasonable size. I would caution you, that coding the way you've implemented RegistryWrite where it always writes everything is conceptually going to bite you in the rear some day when something gets saved you didn't expect. Maybe not this time, but assuming that you know enough to insure the side effect you purposefully put into your code never causes a problem. That's why I changed it to RegistrySaveWindow().

[sharkcutup]

It seems better. It leaves alone my registry changes so the windows are a reasonable size. I would caution you, that coding the way you've implemented RegistryWrite where it always writes everything is conceptually going to bite you in the rear some day when something gets saved you didn't expect. Maybe not this time, but assuming that you know enough to insure the side effect you purposefully put into your code never causes a problem. That's why I changed it to RegistrySaveWindow().

In bold above --- I did not enter any of your registry changes that you noted. I only changed the Window sizes that you had noted in one of your previous posts to accommodate your setup.

I also made changes to the Text Headings that you noted too!

Sharkcutup

[Adrian]

I do. There must be a way to query Windows to find out the current screen size and resolution to make more intelligent choices when sizing windows but I don't know enough about LUA to know if there is a way. I'm used to .NET and then it's easy.

The display is via the browser interface with HTML so scaling etc should be handled within that so it's more of a HTML/CSS/Javascript etc coding issue than LUA.

Been a long time since I developed a gadget for anything other than my own use so I'm not sure if dialogs can scale dynamically within the browser with callbacks etc.

[sharkcutup]

Correct Adrian I have been able to scaling accomplished in HTML. As of now Just haven't found a way to get that HTML to work within the LUA coding strategy. And I haven't given up yet either.

Sharkcutup

[ira]

I'm not looking for how to scale, more for how to size the window on startup. I'm not even sure what information is really needed, but if you could get screen dimensions you could likely get anything else needed to make an educated guess. Then again if WindowWidth and Height worked you could just save the last setting and all would be fine. Once it stopped setting the registry back to the default values and I could just edit the registry to put in decent numbers for me, it was fine, but saving them would be better.

[adze_cnc]

Lua is meant to be lightweight and easily portable and thus is quite stripped down to the bare metal. To get screen resolution would rely on communicating with an API (probably written in C as Lua communicates most readily with that) that would then query the Windows API to get the screen co-ordinates. Much like .NET does.

To make matters worse, Lua is embedded into the Vectric products so you can't really write you own C routines and call them (I'm not 100% sure on C co-routines so I may be wrong).

Perhaps Javascript can be used to query the screen dimensions and dynamically re-size the Window from the size specified by the Vectric API call to create a browser dialog?

I'm curious... what is the diagonal measurement of your monitor?

[ira]

This laptop is 16" diagonal, the 2 monitors on my desktop are 32 I think. All are 4K.