problem hiding not existing cores per CPU measure

[Yue]

Yincognito » Today, 2:41 am
I think the length of my replies is the problem - I tend to make my posts longer than optimal in order to cover everything I want to transmit.
(...)
So, I'll keep it shorter this time, to make it easier: I don't think your suggestion about colors in the current form is the best idea for the tooltips of my skins, which is a real pity because otherwise similar coloring to the main skin makes perfect sense. (...) I just need to find a way to implement it properly, without potential drawbacks in other areas of the code.
The main obstacle here is, like explained in the other thread, the fact that regex doesn't care about the meaning of the pattern. Since the latter are so diverse because the data and its logic are also diverse in the tooltips, that would mean I'd have to use different patterns for tooltips of different skins, something I wanted to avoid all along (one tooltip with a very generalized and abstract structure is best in this case).

I have the same problem very often, never have been the type of "just three sentences".^^

I understood that when you later wrote about how data is fetched. I only wanted to complete the first two suggestions in a no-way-to-missunderstand-anything clear way.
Regarding your code structure and your interest to avoid individual skin-based tooltips I wrote the suggestion in the end of my last post, instead of creating more diversity keeping colors more simple to fit different scenarios without drawbacks. Then there is no reason not to use the ones you already have in the menu, only they won´t resemble the same sort of output. But in that scenario it wouldn´t be a problem and just fit the style of the suite.

Not necessarily how you would do it, but you'd like it to be if you were an user of such a skin. A "what if" scenario, if you like.

Stating the self-evident agin? No, I know, you wanted it to be crystal clear after I asked about it. Surely not only how I would do it. That wouldn´t be helpful. Those questions I approach by a cumulation of starting with what I would want and then extending to what else others "could" want (very much standard approach). So about your asked "what if" scenario also regarding your post before:

Yincognito » Yesterday, 9:08 pm
But let's put it another way, hopefully crystal clear

That much was clear, sure, but it irritated me you writing about "cores" so I asked to avoid missunderstandings.

In other words, if I would scroll through logical cores, I wouldn't display the whole list of logical core frequencies, usages and temperatures when I'm on the single / overall physical processor that we all have, but I would instead display each logical core data in its own "navigation page", if you will, according to the scrolling. For example...
- no scroll: tooltip made of logical core count, frequency, usage, temperature for the single (or overall) physical processor
- scroll once: tooltip made of current logical core number aka 1, frequency, usage, temperature for the logical core number 1
- scroll twice: tooltip made of current logical core number aka 2, frequency, usage, temperature for the logical core number 2
... and so on ...

The disadvantages, as I said, are not viewing all core data on the same page anymore, and the counter for the average and period over which the average is measured not starting until the said logical core is scrolled over. The advantages are multiple and significant, at least in terms of development and efficiency, so I'd prefer it, as the skin designer. My question was what would you prefer, as a hypothetical user? Do you think this (scrolling over logical cores this way) would be acceptable / illustrative / match expectations or user needs?

I agree on the "noscroll". It´s a short and overall view with all necessary data accessed quickly on the fly, which can be useful to everybody, no matter if it´s a standard user, gamer, programmer...

But I disagree on scrolling for each logical processor step by step.
I get the dilemma, because I suppose you would do that by changing the number of the logical processor to fetch per scrolling and regex [similar to how you helped me with my drives - and that much I get from your "Note"] and this method would reduce the code to 1/32 (since you wrote 32 is the maximum you want to do) besides the regex and scrollaction parts.
I cannot think of any reason why someone would want to look at one logical processor only. Maybe there are scenarios, but if so those would be very specialised (if I am forgetting about a common scenario maybe someone here can point it out) and I don´t think that´s the kind of users you´re adressing.
A seperated "single view" would deny the option to compare the utilization of logical processors, while a comparison would allow to imagine the processing of workloads better, maybe even unused capacities or small mistakes/damages (but that I don´t know about, that´s guessing, I would ask my trusted tech guru (I don´t have one anymore)). Possibly overclocking could be monitored easier (whether it´s working the way it should). All that by just one look.
And I would think of people who like keeping it minimal with your suite, but at the same time also find pleasure in the "Oh, look at this, that many (logical) processors I have - and there are their values", besides those idiots who like to brag about it (not knowing more cores (and therfore more logical processors) don´t always mean better performance), pretty much like "Hi, I am Ben and I have an iPhone".
I know, your suite is all about minimalism, distributing lot of information while keeping the visuals as small as possible (that´s why I agreed on not using graphs or something like that), but having a little glance here and there would be the thrill to some users.

I hope that helps at least a little thinking of a few perspectives.

Not overkill, but the, who doesn't like a skin made of just a couple of measures?

[Yue]

It took a while but by now I were able to implement some stuff and have been reading about HWiNFO (first this one, after that I will do the same for MSIAfterburner). For now it´s only about clock speed (temperatures later).
I have a few problems answering easy questions myself since I am testing this on a not-multithreading-dual core.
As far as I understand in the shared memory viewer I can see the clocking per physical core at "Core 0 clock", "Core 1 clock" and so on, and the logical processor speeds at "Core 0 T0 Effective Clock", "Core 0 T1 Effective Clock", "Core 1 T0 Effective Clock", "Core 1 T1 Effective Clock" and so on - is that correct?
If so, then I don´t get how to fetch the data. Referring to "Core 0 Clock" and so on, the EntryID follows the same numbering: "0x6000000", "0x6000001", "0x6000002" and so on. But referring to "Core 0 T0 Effective Clock" it´s "0x600000c", "0x600000d" and not going on, because "0x600000e" is used for the average of effective clock (and by the way sticking to the alphabet seems too limited for numbering).
A little helping explanation on that would be great.

[SilverAzide]

It took a while but by now I were able to implement some stuff and have been reading about HWiNFO (first this one, after that I will do the same for MSIAfterburner). For now it´s only about clock speed (temperatures later).
I have a few problems answering easy questions myself since I am testing this on a not-multithreading-dual core.
As far as I understand in the shared memory viewer I can see the clocking per physical core at "Core 0 clock", "Core 1 clock" and so on, and the logical processor speeds at "Core 0 T0 Effective Clock", "Core 0 T1 Effective Clock", "Core 1 T0 Effective Clock", "Core 1 T1 Effective Clock" and so on - is that correct?
If so, then I don´t get how to fetch the data. Referring to "Core 0 Clock" and so on, the EntryID follows the same numbering: "0x6000000", "0x6000001", "0x6000002" and so on. But referring to "Core 0 T0 Effective Clock" it´s "0x600000c", "0x600000d" and not going on, because "0x600000e" is used for the average of effective clock (and by the way sticking to the alphabet seems too limited for numbering).
A little helping explanation on that would be great.

You appear to be using the old HWiNFO plugin which uses shared memory. That is no longer needed. HWiNFO 7.x can output data directly to the registry, no plug-in needed. It is much easier to configure.

[Yue]

SilverAzide » 39 minutes ago
You appear to be using the old HWiNFO plugin which uses shared memory. That is no longer needed. HWiNFO 7.x can output data directly to the registry, no plug-in needed. It is much easier to configure.

I am not sure what is "used". The plugin.dll appears in some folder, maybe a leftover or it came with a downloaded suite before when I weren´t interested in that program yet. I read about the program, then the thread of Jeffrey Morley and started this way trying to understand the program and how to use it with Rainmeter. Well, found out, the program must be launched (like Winamp if creating a music player skin) and because of that didn´t get what the plugin .dll is for then (your post explains that now). I even found out the few preference changes to fetch the data with Rainmeter from HWiNFO, because it didn´t work in the beginning. For comparison and that way better understanding I looked at your suite and Yincognito´s.
So it´s been a little confusing. Fine, the plugin isn´t needed anymore, just the program (already had the newest version). How does this method about output to the registry work? Would you give me an example code snippet or something that explains this, please?

By the way, the orignial question will remain since I got it from looking at the actual version of HWiNFO and comparing to different skin codes.

[Yincognito]

For comparison and that way better understanding I looked at your suite and Yincognito´s.
So it´s been a little confusing. Fine, the plugin isn´t needed anymore, just the program (already had the newest version). How does this method about output to the registry work? Would you give me an example code snippet or something that explains this, please?

By the way, the orignial question will remain since I got it from looking at the actual version of HWiNFO and comparing to different skin codes.

Take a look here, and feel free to ask if you don't understand something from those steps.

By the way, I don't use HWInfo64 in my suite - when I designed it, the HWInfo64 process was the "old, cumbersome" way like in the thread by jsmorley you mentioned. Even now, even though the process is greatly simplified, the user still has to perform various actions on his own to set up the sharing of data with Rainmeter via registry, while in MSI AB (while it lasts, at least) the referring to various data is done in a much more general way (i.e. the user only needs to install and run it, no other manual labor required other than writing some GPU / SourceId / DataSource / etc. options in the skin code).

[Yue]

Yincognito » Today, 2:15 pm
Take a look here, and feel free to ask if you don't understand something from those steps.

Thank you. Seems to be the easiest to find if searching for it - but didn´t.

By the way, I don't use HWInfo64 in my suite - when I designed it, the HWInfo64 process was the "old, cumbersome" way like in the thread by jsmorley you mentioned. (...) while in MSI AB (...)

I only wrote (well, not that clearly), I took a look at the two suites to learn from them, not that I found about HWiNFO in both codes - but also about the MSI Afterburner and that indeed is the reason I mentioned to get informed about next (so eventually your help will be required in the near future ).
In fact I look at many skins, but always also jump between yours and SilverAzide´s to learn more about how things can be done and about different apporaches, so I don´t have to ask that much.

But I didn´t know it was so difficult to use in comparison, because I haven´t read about MSI Afterburner yet and thought I should get to know that one first and then look at the other, then much more being able to compare them. Maybe I should first continue my reading after the thread you linked and then get to the code...

[Yincognito]

But I didn´t know it was so difficult to use in comparison...

It's not that the HWInfo64 integration with Rainmeter was / is difficult to use, it's only that it requires some extra steps from the user compared to the MSI Afterburner variant (and since not all users are tech savvy, it can result in complications, questions you have to answer as the skin designer, etc. - you get the idea). Simple example...

MSI AB:

Code: Select all

[CPU1Temp]
Measure=Plugin
Plugin=MSIAfterburner.dll
DataSource=CPU1 temperature

HWInfo (old way):

Code: Select all

[MeasureCPUTemp]
Measure=Plugin
Plugin=HWiNFO
HWiNFOSensorId=0xf0008686
HWiNFOSensorInstance=0x0
HWiNFOEntryId=0x1000002
HWiNFOType=CurrentValue

HWInfo (new way):

Code: Select all

[MeasureCPUTempValueRaw]
Measure=Registry
RegHKey=HKEY_CURRENT_USER
RegKey=SOFTWARE\HWiNFO64\VSB
RegValue=ValueRaw102

In the case of both the old and the new way in HWInfo64, the values of the said options require additional actions from the user (e.g. checking the shared memory viewer for the old version, or ticking stuff and taking note of the index value for the new one) and are different from user to user based on various factors, while in MSI AB, a very generic "CPUX Temperature" value for the option is enough and stays the same irrespective of the system is being run onto. Of course, in the "new" version (1,2,0,0) of the MSI AB plugin, most things use the GPU / SourceId combo of options, but they are still very generic and therefore the same code will work without extra steps if copied to another system.