Done a rework of the vbscript as i had the error check in the wrong place so it still found the other adapter when it should of exited the vbscript. Now two checks are done and should exit and trigger the wmic routine. I uploaded to the test area the rc1 qt, but cant seem to access convos on my phone as im at work.
For some reason the qt not run properly from a pshell prompt or if a pshell window open so i put that check in to prevent false qt results. I forgot i added that check in, it was, if i remember that a couple of qt users found problems when pshell was used or detected running.
I think winpe is checked for too and will exit the qt as winpe not have some os parts the qt requires such as .net stuff.
Interesting that the vbscript still continued and shown the Adapter 2 data even with a forced script quit if any Adapter has no Video Ram It is hard to replicate so i can make adjustments so for now i will leave that section alone or it could get very confusing
It's strange, did you change the query? It doesn't even return the inactive adaptor anymore, thus no error can be set and exit the script?
i have just now added the on error bit and test for script failures to QT 110 rc2 and uploaded that with the edited vbs in the zip. That *should* abort the vbs and make the QT use the WMic routine... if this dont then i am at a loss why it fails to exit vbs - may have to return it back to original one so that a error is given... Have a works meeting and then a few jobs to catch up about the home before i head off to work later so i be able to reply until later this evening. The query in rc1 is the same i just checked for adapterram being nothing (non existant) then exited but it seems vbs had other plans.. On error in vbscript is not as good as VBasic as you have limited options in vbs, but it should work - you can view the vbs and see i have checked at a few points where an error may occur and quit the script - *if* i got the check right.
I have checked (inserted an Echo line) and The Error variable is NOT set to 1, it stays at 0. The initial query cannot have data about adaptor 1, as the error routine passes with Error 0. If it was present, it would be shown, then, no?
I may have to re-write the vbs at some point as that one was designed that if there was more than 4GiB vram it should of been shown correctly, but as the API is limited to the 4GiB max then the routine used is relatively wasted. There again i may just remove it totally and let wmic do its job as it is roughly the same routine but simpler to work with, i was just trying to get better results. Will see when i get a bit of spare time to have a rethink about the vbs side. As mentioned the On Error bit on vBscript is a bit limited.
QT 110-RC3 Have tweaked the vBscript with more checks and i tested with a value/object that not exist and the on error check worked and exited the vbs so that Wmic took over While i was on my breaks at work last night i did a bit of reading up on checking vars etc in VBscript and there is so much to understand still, but i tested the theory this morning when i got home and the result is the new vbs script which seems to be working ok... VbScript is weird to say the least in that say you want to check a variable is nothing or empty, with cmd script you check with 'IF "%TestVar%" = "" blah blah' or 'IF NOT DEFINED TestVar blah blah' , so easy BUT In VbScript you have to be creative, so if testvar is null/empty/not exist you need to use 'IF IsNull(TestVar) OR IsEmpty(TestVar) then blah blah' also error control is quite fussy too... So the new vbscript will check if the objectitem (AdapterRAM in this case) exists or is empty then set the error routine and exit to force WMIC to take over, there is a bit more involvement in the script but that is the general idea. I was not going to let this beat me, sadly the 4 GiB limitation has for now... If this works, ( or if it fails then i remove the vbs part totally ), either way the QT v110.0 is about ready for release.
Looks like the new vbs checking worked and exited to allow the Wmic part to operate... Plus showing the correct configuration (in this scenario) of the 'dual' gfx adapters.