23 replies to this topic

[larioteo]

Hello found a bug and don't know if anyone has mentioned it or using it.


RegImport,Path\*reg

Its not important wich reg file u use, binary values are following writed wrong

Should be:
hex(7):52,00,70,00,63,00,45,00,70,00,74,00,4d,00,61,00,70,00,70,00,65,\
00,72,00,00,00,52,00,70,00,63,00,53,00,73,00,00,00,00,00

Is with RegImport:
hex(7):52,00,00,00,00,00,00,00,70,00,00,00,00,00,00,00,63,00,00,00,00,\
00,00,00,45,00,00,00,00,00,00,00,70,00,00,00,00,00,00,00,74,00,00,00,00,00,\
00,00,4d,00,00,00,00,00,00,00,61,00,00,00,00,00,00,00,70,00,00,00,00,00,00,\
00,70,00,00,00,00,00,00,00,65,00,00,00,00,00,00,00,72,00,00,00,00,00,00,00,\
00,00,00,00,00,00,00,00,52,00,00,00,00,00,00,00,70,00,00,00,00,00,00,00,63,\
00,00,00,00,00,00,00,53,00,00,00,00,00,00,00,73,00,00,00,00,00,00,00,00,00,\
00,00,00,00,00,00,00,00,00,00,00,00,00,00


I also know what is going wrong, look:

An snippet of the good one:
52,00,70,00,63,...
and the bad one:
52,00,00,00,00,00,00,00,70,00,00,00,00,00,00,00,63,...


Problem Seems to be that Winbuilder simply adds after every normal value 3 00 automatically.
For me it looks so:

(Fat Values are wrong and made by winbuilder)
RegWrite: 52 000000 00 000000 70 000000 00 000000 63


It seems very simple and should be as soon as possible fixed.

[pscEx]

I confirm that it the result is unexpected and objectively wrong.

But it cannot be fixed easyly.

WinBuilder uses the Original Delphi function
TRegFile.LoadFromFile(<filepath>);

Peter

[larioteo]

Maybe an alternative could help, don't know delphi but someone should have a solution for this, otherwize delphi is useless for reg operations. I understand you mostly the sdks are buggy and we devs need to find workarounds.

Hmm as i see you have an extra function for regwrite bin surely cause of this, maybe an extra function for such things would help or an extra .reg file to seperate such values and so on.

[pscEx]

This works:

Use Reg2WBs to convert the *.reg into WinBuilder script code.

This code is understood correctly.

Peter

[larioteo]

OK,

i see that even microsoft cant manage it with its own regedit.exe fiel correctly and as i always said i don't need workarounds to make a script in winbuilder i rather would use the direct way, cause its

1. faster
2. better
3. it reports an error if writing fails, regedit exe not... (i tested it very good)


Only the reg.exe seems to work good from ms, but no wonder why the regedit.exe parameters arent normally documented by microsoft in a standard installation like all other tools.

I see that the other devs are trying to kill the builder with their workarounding workarounds, but its a stupid way for every developer, we must correct the errors and bugs of the elite coders...

Explorer script has written two times the same stuff but the second time the folder where they are "unpacked" is deleted and regedit exe deosnt reported no file or file is missing. Its a big mess what is currently running around.

Edited by Darijo, 15 November 2011 - 08:49 AM.

[paraglider]

Think there is no choice but to write Delphi code in winbuilder to manually parse the reg file.

[pscEx]

Think there is no choice but to write Delphi code in winbuilder to manually parse the reg file.

I'm afraid you are right ...

Peter

[paraglider]

Or port to Lazerus Pascal ( free ) or the latest Delphi version probably an easier port ( not free - Delphi XE2 pro is $899, starter edition is $199 ). At least then you would be using a supported platform. Maybe the community would buy you a copy.

I suspect neither will happen.

[Wonko the Sane]

Why not using the MS "Oflline Registry" .dll?
It is redistributable allright.
http://reboot.pro/in...showtopic=11212

Or does it suffer from the same "misunderstandings/mistranslations"?


Wonko

[homes32]

Or port to Lazerus Pascal ( free ) or the latest Delphi version probably an easier port ( not free - Delphi XE2 pro is $899, starter edition is $199 ). At least then you would be using a supported platform. Maybe the community would buy you a copy.

I suspect neither will happen.

All that would be needed would be for 90 people to donate $10 or 44 peope to donate $20.
I suspect there would be some people willing to do so if they knew it would make a substantal difference in quality and speed of Winbuilder. perhaps embarcadero would even be willing to make a deal in excange for a banner on the site or something.

[Wonko the Sane]

All that would be needed would be for 90 people to donate $10 or 44 peope to donate $20.

Actually 45 people would be needed for second example.


Wonko

[homes32]

Actually 45 people would be needed for second example.


Wonko

knew you would catch that!

[sbaeder]

Are you referring to the Reg2WBs ??

...as i always said i don't need workarounds to make a script in winbuilder i rather would use the direct way, cause its

1. faster
2. better
3. it reports an error if writing fails, regedit exe not... (i tested it very good)

I don't see it as a "workaround", but rather a tool that does the conversion for you - of course, if the registry stuff isn't "static", and you need to change it often, having a function to do this helps.

p.s. I have added a note to the wiki docs about this.

[homes32]

p.s. I have added a note to the wiki docs about this.

also added to list of WB known issues...

[larioteo]

OK i see it is good that it know is mentioned

The builder is for me mostly stable this was the first command that don't did what i awaited from it, so i can live with the converter.

Regedit /s is for me not a good option i rater use reg import, it works for me better and also on x64 builds within sys32, only if the user isnt full admin on his system it is understandable that it sometimes cannot work, as all we know windows is far away from being a perfect system, i am running everything with full permitions and so it works good.

What would be interesting is to combine a lot of commands to one, i know than many others would say o now recoding again, but sometimes a internal intelligent check solves such problems easier than we with our scripts.

As example if winbuilder rans on x64 build and the regread fails, try the same thing with regredirect auto switch and after that turn it fast back. But post the developer a warning to show him hey this part is slowing down your operations cause of auto correction .... and so on

Maybe the little slowdown would be better than an ever stopping build

Also more interesting would be to make the ifs more intelligent.

If,Not,ExistFile,blabalbla,CopyFile,blablabal


I mean if it isnt in the directory copy it from other directory without the option to type in the destination path again, such an intelligence, i know it is hard to check the syntax and to do the right thing, but such things would be nice in a near feature to make it easier for everyone.

If,Not,ExistSection,bablabla,balbabl,AddSection

As example also not bad.... and so on, i believe here are many good ideas, it is only a little suggestion how it would be cool to extend these ifs to a more powerfull tool.

[pscEx]

Some good ideas / suggestions for the next release

If,Not,ExistFile,blabalbla,CopyFile,blablabal

I mean if it isnt in the directory copy it from other directory without the option to type in the destination path again, ...

Something like:

If,Not,ExistFile,blabalbla,CopyFile,blablabal

Else,TryDir,FirstDir,SecondDir,ThirdDir

?
Not so easy, because the If handling evaluates conditions. It does not know the logical contents of the conditions.
But I'll give it a trial.

If,Not,ExistSection,bablabla,balbabl,AddSection

This functionality is not necessary, because IniWrite creates the section, if it does not yet exist.
If,EXISTSECTION, ... is used only very rarelly, e.g. to check whether a script has attachements. In this really few cases a second statement to create the section is not too much work for the script author.

Peter

[larioteo]

OK, i try to write it more clear.


If,Not,ExistDir,%TargetDir%Test,Create
If,Not,ExistFile,%TargetDir%test.txt,Create

Here my suggestion is that the If functions get some extra options, the create behind is the second command that is executed after the check if the result is true then create sees that the developer asked for a directory or a file and it sees also the path or file of the question. So after that Create calls automatically as example the existing command DirCreate or FileCreateBlank and gives it the parameters needet. All handlet internal with jumps. I think it is not hard to do something like that.

Also this can be usefull.

If,Not,ExistFile,%TargetDir%test.txt,CopyFrom,%SourceDir%

CopyIfExist,%TargetDir%test.txt,%SourceDir%

also i would compine CopyDir and CopyFile to one command in future. Winbuilder itself should know if it is a dir or a file, for me it would be easier or for others to have 5-10 super commands instead of 20-30 normal commands that to one thing.


Winbuilder now is very powerful only the combnation of some commands can make it more easier to use.

CopyOrExpand is a good example for such an intelligent command

CopyWithMui would be nice for the newer PE builds or

CopyFile,xxx,xxx,WithMui

Don't cares how to add it if the old one works anyway, a litte deprecation is anyway allowed, if someone want to use it.

it is self explaining.

[sbaeder]

While we are at it, maybe we could go all the way to an APL like syntax that no one can understand (unless they live in it it 100% of the time)

Seriously, I think the "power" is there already ...So the argument is really about how hard it is to get the functionality. Would we want to be coding in assembly language? Probably not. Super complex operators like APL - again...probably not. BALANCE is what we need! Easy enough to write human readable/understandable on the intent of what we as the writer want to accomplish, and efficient enough for the compiler/interpreter to process.

Some of the suggestions might have some merit...As for "copy with MUI", isn't that what the "RequireFile" already does??? And don't forget, that you can always encode or create API like commands, and if sufficient interest and discussion, propose we add them as "standardized"...

But good ideas to discuss...(in new topic ???)

[Wonko the Sane]

Yep, if I may we are mixing BUG reports with wished features right now.

Additionally HOW exactly one wants to shoot oneself in the foot:
http://www.kirchwitz...hoot_foot.shtml
is yet another issue, IMHO.


Wonko

[larioteo]

RequireFile isnt that good as you think, no wildcardsa and automatically in System32 dir, i know so wanted it everyone, but imagine a command should do his work and not think where the file could be. And it is very very slow, to add it in builder as param after CopyFile, wouldn't kill anybody, we have an CopyOrExpand that does more than other commands, so a new parameter after copyfile wouldnt harm the Performance or the Compability.

What is more important, syntax that is easier to write on your own, or the usage of commands that arent fixed and developed by others.
New Features that doesn't harm old scripts should be a good solution, when a new dev (like me) comes here he than can write his scripts more easy the old devs can use der capi or anything like that, they will anyway maybe switch to new commands.

It is like from 080 to 082 with the performance boost, everyone is going in this direction cause it works faster why not? I found some bugs in the capi also, cause i need a workaround to redirect their commands that app scripts also work in my project, readenv i have simply deactivated in capi, nothing stands there, and everything works, inivariables the new feature is for me also not neccessary, sometimes it seems that they fix imaginary bugs of the builder instead of posting it and searching the bug in their scripts.

If you have your code only in the one script the debugging is very easy if you have 100 redirections like in capi you either will not found anyhting (so i do), sometimes i understand the commands and find them usefull, sometimes i see commands that arent so usefull like ReadEnv. nothing against anyone but sensless stuff is for me a slowdown for a project and not the future.

[sbaeder]

Yes, it has limitations...I agree that it MIGHT make sense for an "extension" to the syntax...I was just saying that on anything like this - an extension to the syntax, a new "API" like routine even if more streamlined, or anything else would need to have some careful consideration, discussion, and even a clear set of usage docs created before we push ahead...

That is why suggested you start a new posting to propose and get feedback on this.

[larioteo]

Where to post it? i dont see a wishes or suggestions topic under winbuilder forum.

[patsch]

then create a topic

[pscEx]

In former times we have had something like 'Suggestions' or 'Requests'.

But I cannot find that subforum, too.

BTW: To open the formular to type this post, needed about two minutes.

?????????

Peter