242 replies to this topic

[Lancelot]

what should I do to fix ???

Found,

[main]

value1=##$c##$ztest1

value2=test2

give me some minutes to prepare something here, I hope JFX will like too

[was_JFX]

@JFX

Please test with adding experimental escape strings to 0x7 registry, have fun.
example: prepare a 0x7 value with something like
string1=#$ctest1
string2=#$ztest2

I hope it works.....

Not sure what you mean #$s is the only thing make sense in 0x7 and it works.

[Lancelot]

@JFX
well if things works nicely for you, than there is no problem to me (I will test in some hours). I honestly boxed with psc for your and fxscrpt's troubles (as far as I remember) with 0x7 and to avoid future troubles with wb for similar cases.

Follow the idea, what you think ? .

@all

An idea to burry all Regwrite-0x7 and releated things forever,
(there is also another idea similar to below involving hex values as paraglider pointed, but for now i will stick on strings to explain)

RegRead,<HKEY>,<Section>,<Key>,<%Variable%>[,<%Counter%>][,<%Type%>]
or
RegReadString,<HKEY>,<Section>,<Key>,<%Variable%>,<%Counter%>,<%Type%>


giving example:
RegHiveLoad,WB-Software,%target_sys%\config\software
RegWrite,HKLM,0x7,WB-Software\PSC,DisplayName,string1,string2,string3
RegRead,HKLM,WB-Software\PSC,DisplayName,%DisplayName%,%DisplayNameTotal%,%DisplayNameType%
RegHiveUnLoad,WB-Software

When optional parameters used, this would assign 3 variables to wb

%DisplayNameType%=REG_MULTI_SZ
%DisplayNameTotal%=3
%DisplayName1%=string1
%DisplayName2%=string2
%DisplayName3%=string3

which as a result one can add things (by checking IF,ExistVar etc etc) anywhere with some process (no need warnings ).

and this solution also avoids escape, if there is escape in variable values, wb can automagically add # to these values

Giving Example:
If DisplayName value is:
string1#$z#$c
string2#$c#$z
string3

result will be

%DisplayNameType%=REG_MULTI_SZ
%DisplayNameTotal%=3
%DisplayName1%=string1##$z##$c
%DisplayName2%=string2##$c##$z
%DisplayName3%=string3

.....blabla

I hope understood ???? what you think ?

[was_JFX]

Seems a bit complicated, you only check if a line exist in REG_MULTI_SZ?

[Lancelot]

Not sure what you mean #$s is the only thing make sense in 0x7 and it works.

JFX, test this:

first lets create a registry including escape charecters:

RegWrite,HKCU,0x7,Software\11,IniReadTest,String1##$c##$s,String2##$s##$z,String3##$c##$z

check your registry to see the result

now try this
RegAddMulti,HKCU,Software\11,IniReadTest,APPEND,Stringapp

I guess this can be fixed with current RegAddMulti on next trash, psc ?



@psc
"Extract To Desktop" still not working (written previously on current topic at post 14)

fixed - bug in download center: On first show tree was allways built, regardless of 'green arrow' definition

On first show, tree not build anymore (thanks, this gain lots of time), but still downloading index.html regardless of 'green arrow' , I am not sure it is intented that way, why should I need to download new index.html from previous selection if my aim is changing server !!!

[was_JFX]

Now I get it

[Lancelot]

Seems a bit complicated, you only check if a line exist in REG_MULTI_SZ?

NOOOOOOOOOOOOO.

follow the example,

lets create a registry to be read later:

RegWrite,HKCU,0x7,Software\11,NewcommandTest,"System Reserved","Boot Bus Extender","System Bus Extender","SCSI miniport"

my request is:

RegRead,HKCU,Software\11,NewcommandTest,%NewcommandTest%,%NewcommandTestTotal%,%NewcommandTestType%

and for wb result should be something like following:

%NewcommandTestType%=REG_MULTI_SZ
%NewcommandTestTotal%=4
%NewcommandTest1%="System Reserved"
%NewcommandTest2%="Boot Bus Extender"
%NewcommandTest3%="System Bus Extender"
%NewcommandTest4%="SCSI miniport"

now what you think ?

[Galapo]

added - Variable %WBExe%

Thanks for that Peter! This will simplify the ".exe and changelog" script as special .au3 program previously had be used to detect running WB executable (necessary for when WB exe has been renamed, say 'WinBuilder-078sp7.exe'.

Regards,
Galapo.

[Galapo]

added - RegAddMulti command

RegAddMulti,HKLM,Section,Key,APPEND,String

   RegAddMulti,HKLM,Section,Key,PREPEND,String

   RegAddMulti,HKLM,Section,Key,BEFORE,SubVal,String

   RegAddMulti,HKLM,Section,Key,BEHIND,SubVal,String

   RegAddMulti,HKLM,Section,Key,PLACE,Index,String

   RegAddMulti,HKLM,Section,Key,DELETE,SubVal

Hi Peter,

Thanks indeed for this! Really fantastic.

For my "Add/Remove UpperFilters" script I could remove the AutoIt script now I think.

Thanks,
Galapo.

[Galapo]

Thanks! I'll prohibit that (tomorrow)
BTW: I think that all methods make it possible, because currently I do not check the presence of the string before write.

Is it feasible to check whether the string already exists and if so delete it and then write it back in to the position indicated by the command? Or is it better to just warn in the log and if a script needs a particular ordering then it should you 'DELETE' and then the other desired command, say 'PREPEND' or 'BEFORE'?

Regards,
Galapo.

[pscEx]

Is it feasible to check whether the string already exists and if so delete it and then write it back in to the position indicated by the command? Or is it better to just warn in the log and if a script needs a particular ordering then it should you 'DELETE' and then the other desired command, say 'PREPEND' or 'BEFORE'?

Regards,
Galapo.

I prefer the second alternity. My opinion is that ALLWAYS the programmer has to decide, never the program.
To make that possible, I did some changes:

changed - improved syntax check with warnings / errors in RegAddMulti command
added - RegAddMulti,HKLM,Section,Key,INDEX,SubVal,%Index%
added - If,EXISTREGMULTI,HKLM,Section,Key,SubVal,Command


To test the new checks / functions you can try my standard test:

[process]

RegHiveLoad,WB-Software,%target_sys%\config\software

RegWrite,HKLM,0x7,WB-Software\PSC,MultiInside1,one,two,three,five,six,seven

If,EXISTREGMULTI,HKLM,WB-Software\PSC,MultiInside1,three,Echo,YES

Else,Echo,NO

If,EXISTREGMULTI,HKLM,WB-Software\PSC,MultiInside1,xxx,Echo,YES

Else,Echo,NO

RegAddMulti,HKLM,WB-Software\PSC,MultiInside1,INDEX,TWO,%var%

Echo,%var%

RegAddMulti,HKLM,WB-Software\PSC,MultiInside1,APPEND,bla

RegAddMulti,HKLM,WB-Software\PSC,MultiInside1,APPEND,TWO

RegWrite,HKLM,0x7,WB-Software\PSC,MultiInside2,one,two,three,five,six,seven

RegAddMulti,HKLM,WB-Software\PSC,MultiInside2,PREPEND,bla

RegAddMulti,HKLM,WB-Software\PSC,MultiInside2,PREPEND,TWO

RegWrite,HKLM,0x7,WB-Software\PSC,MultiInside3,one,two,three,five,six,seven

RegAddMulti,HKLM,WB-Software\PSC,MultiInside3,BEFORE,TWO,bla

RegAddMulti,HKLM,WB-Software\PSC,MultiInside3,BEFORE,XXX,BLA

RegAddMulti,HKLM,WB-Software\PSC,MultiInside3,BEFORE,three,five

RegWrite,HKLM,0x7,WB-Software\PSC,MultiInside4,one,two,three,five,six,seven

RegAddMulti,HKLM,WB-Software\PSC,MultiInside4,BEHIND,TWO,bla

RegAddMulti,HKLM,WB-Software\PSC,MultiInside4,BEHIND,XXX,BLA

RegAddMulti,HKLM,WB-Software\PSC,MultiInside4,BEHIND,three,five

RegWrite,HKLM,0x7,WB-Software\PSC,MultiInside5,one,two,three,five,six,seven

RegAddMulti,HKLM,WB-Software\PSC,MultiInside5,PLACE,2,bla

RegAddMulti,HKLM,WB-Software\PSC,MultiInside5,PLACE,10,two

RegAddMulti,HKLM,WB-Software\PSC,MultiInside5,PLACE,2,two

RegAddMulti,HKLM,WB-Software\PSC,MultiInside5,PLACE,three,blabla

RegWrite,HKLM,0x7,WB-Software\PSC,MultiInside6,one,two,three,five,six,seven

RegAddMulti,HKLM,WB-Software\PSC,MultiInside6,DELETE,bla

RegAddMulti,HKLM,WB-Software\PSC,MultiInside6,DELETE,two

RegHiveUnLoad,WB-Software

BTW: New version from trash is needed!

Peter

[Lancelot]

Request for RegWriteBinary:

RegWriteBinary,<HKEY>,<KeyType>,<Section>,<Keyname>,<Value>

Reason:
I can not write Thai localization infos to registry:

Example:
for thai, localization value for sNativeDigits on registry is

๐๑๒๓๔๕๖๗๘๙

with using reg2wbs, I get this
RegWrite,HKLM,0x1,"WB-Default\Control Panel\International",sNativeDigits,ðñòóôõö÷øù
and this writes wrong info to registry

Remembering this is about missing unicode support all because of delphi not providing things freely, I can write right info to registry with regwritebinary by using winbuilder:
RegWriteBinary,HKLM,0x1,"WB-Default\Control Panel\International",sNativeDigits,50,0E,51,0E,52,0E,53,0E,54,0E,55,0E,56,0E,57,0E,58,0E,59,0E,
00,00

or by using pre made .reg files.

edit: post moved here

[Lancelot]

Also reminding 3 small issues that are forgotten.

"Extract To Desktop" still not working (written previously on current topic at post 14)

On first show, tree not build anymore (thanks, this gain lots of time), but still downloading index.html regardless of 'green arrow' , I am not sure it is intented that way, why should I need to download new index.html from previous selection if my aim is changing server !!!

"Rebuild download tree only on on green arrow click (makes green arrow visible)"
1) typo: on on

[pscEx]

Request for RegWriteBinary:

RegWriteBinary,<HKEY>,<KeyType>,<Section>,<Keyname>,<Value>

Reason:
I can not write Thai localization infos to registry:

I'm sorry, I do not understand any more.

I do not know RegWriteBinary ????? Who introduced this command in the WinBuilder version under discussion ?????
And I never got some questions / requests / issues about Thai

Why now, where my question in post #1 was whether the current WB version is suited to be used for CURRENT projects ??????

Let's go to this first post 'translated to simply question': Can this (or the current trash) be used to run current projects?

Or should we wait until all currently open or suspected Thai, Chinese, Japanese, Arabic, (maybe also Greek, Russian etc. ) issues are theortically solved (inspite some of them are currently not actual).
BTW: "Theoretically solved" means that in the first actual use of such a language with high propability new issues come up, because the tests are made in the sandbox by sandbox generals.

(Remember above: Can this (or the current trash) be used to run current projects?) If yes, I will publish.

Nobody is perfect. And I do not see ANY reason not to publish the fastest and most powerful WB version we ever have had, because it has troubles to work with Thai.
Thai should be one of the tasks for the next version.

If not, I'm waiting for a description of the demanded NECESSARY changes.
But please not simply : "Support Thai".
After that we can go on.
Until then, no more response by me in this topic.

Peter

[Lancelot]

current WB version is suited to be used for CURRENT projects

we do not even need RegAddMulti for CURRENT projects , all scripts already uses workaround which I try to explain to you for a loooooooooong while.

I requested following
RegRead,<HKEY>,<Section>,<Key>,<%Variable%>[,<%Counter%>][,<%Type%>]
or
RegReadString,<HKEY>,<Section>,<Key>,<%Variable%>,<%Counter%>,<%Type%>

before you invented RegAddMulti

well, as far as RegAddMulti works nicely for FUTURE (NOT current) with winbuilder scripts and projects, fine to me.

I do not know RegWriteBinary ?????

wrong, I wrote you the request for regwritebinary 1 or 2 days ago, check your archive.

Who intriduced this command in the WinBuilder version under discussion ?????

As seen from previous post, I request this command to get logable with winbuilder.

I wrote a valid real life reason which can not be done internally with winbuilder and request a new syntax that solves . !!! Do you need anything else ??
In the past 0x7 requests made on topics before, than workarounds used, and in the end now we have ~~it. I guess my request needs this route too........

And I never got some questions / requests / issues about Thai

Partially wrong, probably you never get questions / requests / issues about specially Thai but you get questions / requests / issues about Asian Codes (probably Chinese). I remember topics about users asking support to write assian charecters (either for iniread or for regwrite , and probably for chinese) and since the Usual reply is wb not supporting unicode, they get away from things that requires unicode. check old topics asking support for unicode related stuff where you replied.

I am pretty sure our East Asia members (as well as others, reminding world is big) are get used to live this fact of winbuilder.

Availablility of writing binary data (hex) for (as far as I know 0x1 , 0x2 , 0x7) overcomes these cases.

but since you do not want to, as usual there will be workarounds.

If you do not want to, no need to create invalid reasons or recreation of syntaxes.

And so far I read, what ever the good reason behind, you do not want to give availability for RegWriteBinary. Case closed.

Let's go to this first post 'translated to simply question': Can this (or the current trash) be used to run current projects?

If not, I'm waiting for a description of the demanded NECESSARY changes.

I have not get response for minor things on my previous post ????? Extract to WRONG desktop is not necessary for building, but annoying like a bad working FF. Sorry I did not know reading right key from registry is that much hard.

And further, As far as I know, this topic created to make tests and final requests for a trustable winbuilder that can be used and adviced for all projects including LiveXP directly after published.

So far I have 11 trash version including last one (and missed 1 or 2 in between). With not being a coder but a supporter, I did my best to find things on current topic by testing some of these trashes either fully or partially and tried hard to explain things to you on this topic and on ICQ (I guess to get rid of 0x7 none logable workaround, we made 2 ICQ chats which we spend 2 days, and remember previous times before this topic me and others requesting fixes for 0x7 cases numerous times).

So I understand you wrong, I was planing to remake my build tests after we say things over, checking bug reports, making download tests with fake server. From your post now I see spending lots of time on these are not necessary because you already made your decisions to publish.

No problem to me, since you set back to your old publish behaviour, than as usual we can wait 2 weeks after publish to get reports from end users for new winbuilder with LiveXP. Since 077RC2 we are doing this and most critical bugs after wb077rc2 found by LiveXP project by end user reports. Yes it is a slow development, but since the decision made to make things slowly, no problem to me.

Sorry for spending lots of time on this, I totally understand the intentions of this topic wrongly. If I knew I would not spend all these times. As usual please do as you like. If new version is good and no critical reports made within 2 weeks, naturally livexp will have next version.

[Galapo]

[b]changed - improved syntax check with warnings / errors in RegAddMulti command
added - RegAddMulti,HKLM,Section,Key,INDEX,SubVal,%Index%
added - If,EXISTREGMULTI,HKLM,Section,Key,SubVal,Command

Excellent, will do what we need.

Thanks,
Galapo.

[pscEx]

New version on trash

added - %RegDataType% variable set on every successful RegRead operation
added - RegWriteBin command to write wide strings
added - RegReadBin command to read wide strings

Peter

[Galapo]

Hi Peter,

There's a bug with CopyOrExpand not accepting PRESERVE and NOWARN passed as parameters.

http://www.boot-land...?...ost&p=91067

Thanks,
Galapo.

[pscEx]

Hi Peter,

There's a bug with CopyOrExpand not accepting PRESERVE and NOWARN passed as parameters.

http://www.boot-land...?...ost&p=91067

Thanks,
Galapo.

new version uploaded to trash:

fixed - bug in scriptline parameter count check

Peter

BTW: Nuno decided that next Monday the actual trash will be published as stable version WinBuilder 080.

If there are any questions left, there are 4 days to ask them.

[Galapo]

fixed - bug in scriptline parameter count check

Thanks, Peter. CAPI now working!

Just wondering if you fixed Lancelot's issue of file extraction to desktop in scenario where user profile doesn't reside on %SystemDrive%?

Thanks,
Galapo.

[pscEx]

Just wondering if you fixed Lancelot's issue of file extraction to desktop in scenario where user profile doesn't reside on %SystemDrive%?

I can't.

This is the code I use:

lib := GetEnvironmentVariable('SystemRoot') + '\system32\shell32.dll';

  h := LoadLibraryEx(PAnsiChar(lib), 0, LOAD_LIBRARY_AS_DATAFILE);

//	21769	"Desktop"

  s := GetEnvironmentVariable('UserProfile') + '\' + getResString(h, 21769) + '\';

I do not see any reason why in Lancelot's case the OS tells me the wrong desktop path.

Next Upload will have the value from registry. Maybe that helps.

Peter

[pscEx]

Next Upload will have the value from registry. Maybe that helps.

Uploaded

changed - improved syntax check with warnings / errors in RegWriteBin / RegReadBin command
changed - Desktop path now read from registry

BTW: The new code is

RegReadInternal('HKEY_CURRENT_USER', 'Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders',

	'Desktop', S);

But the read value is "%USERPROFILE%\Desktop"

And therefore I have to replace:

s := AnsiReplaceText(s, '%USERPROFILE%', GetEnvironmentVariable('UserProfile'));

For me no logical difference to the old solution

Peter

[Galapo]

I agree with you. Path to extract to desktop should be determined by a GetEnvironmentVariable('UserProfile') call.

Could Lancelot's issue be something to do with WB running under x64?

Regards,
Galapo.

[Lancelot]

@Galapo

I agree with you. Path to extract to desktop should be determined by a GetEnvironmentVariable('UserProfile') call.

Could Lancelot's issue be something to do with WB running under x64?

Hi Galapo, the call you use, get UserProfile location, NOT Desktop. It has no relation to x64, I do same settings to all close friends for x86 too.
So far no single issue with any utilities they (or I) use since all utilities get desktop location from registry. (It is a well known information, nothing miracle , check post 14).

When I first made the request (bug request), I also warned psc personally not to use shell32 or userprofile value but use regread value knowing psc has a habit to use shell32.dll or userprofile information for these tasks which is totally wrong (but works since most do not change default location). I warned before, I reminded after, and reminded more detail later. I did nothing wrong.

above code of psc works this way on my hostos:
on my hostos,
First read value with RegReadInternal reads correct value,
and next step do nothing since my value do not contain %USERPROFILE% (but for others who contain %USERPROFILE%)

at least I am happy now that issue gone away for 0x1 values including me. Logic changed, now more ways to Rome.

further:
IF someone else use a different variable (for any reason) than %USERPROFILE%, and IF convertion of value %USERPROFILE% required with AnsiReplaceText in delphi world.... Please Guess and use info on your designs.

[pscEx]

@Lancelot!

Does your explanation mean, that the RegReadInternal on my system reads literally %USERPROFILE%\Desktop,
and on your system the correct path?

Than we can be satisfied, as you already explained in this case the replace code will do nothing.

BTW: If I look into my registry by regedit, I see also the complete path.

Why does Billy's API substitute with %UserProfile% on my system, but does not on yours?

Peter