161 compile no longer working

This forum can be browsed by the general public. Posting is limited to current SAPIEN license holders with active maintenance and does not offer a response time guarantee.
Forum rules
DO NOT POST LICENSE NUMBERS, ACTIVATION KEYS OR ANY OTHER LICENSING INFORMATION IN THIS FORUM.
Only the original author and our tech personnel can reply to a topic that is created in this forum. If you find a topic that relates to an issue you are having, please create a new topic and reference the other in your post.

Any code longer than three lines should be added as code using the 'Select Code' dropdown menu or attached as a file.
This topic is 4 years and 11 months old and has exceeded the time allowed for comments. Please begin a new topic or use the search feature to find a similar but newer topic.
User avatar
Lembasts
Posts: 405
Last visit: Wed Mar 20, 2024 1:40 pm
Has voted: 1 time
Been upvoted: 1 time

Re: 161 compile no longer working

Post by Lembasts »

I am not dotsourcing but what do you mean by resolving scripts please?
And where do I find the encoding?
When I get a chance to reinstall 161 I will try the command line host.
User avatar
Lembasts
Posts: 405
Last visit: Wed Mar 20, 2024 1:40 pm
Has voted: 1 time
Been upvoted: 1 time

Re: 161 compile no longer working

Post by Lembasts »

So it appears to be parsing by 161. These are the errors when running the exe as command line:

Line 10499: At line:10498 char:3
+ {
+ ~
Missing closing '}' in statement block or type definition.

At line:10499 char:158
+ ... vertTo-SecureString -AsPlainText "$($textboxpassword.text)" –Force)
+ ~
The Try statement is missing its Catch or Finally block.

At line:10488 char:23
+ $buttonApply_Click = {
+ ~
Missing closing '}' in statement block or type definition.

At line:10337 char:1
+ {
+ ~
Missing closing '}' in statement block or type definition.

At line:10499 char:158
+ ... vertTo-SecureString -AsPlainText "$($textboxpassword.text)" –Force)
+ ~
Unexpected token ')' in expression or statement.

At line:10501 char:3
+ }
+ ~
Unexpected token '}' in expression or statement.

At line:10536 char:2
+ }
+ ~
Unexpected token '}' in expression or statement.

At line:13442 char:56
+ $errmsg = validate $textboxServiceCall.text "notempty;sdnumbe ...
+ ~
Missing closing ')' in expression.

At line:16489 char:27
+ $TypesData.add("Staff (+non DSTG)", ($usersenabled | where { ...
+ ~
Missing expression after unary operator '+'.

At line:16489 char:27
+ $TypesData.add("Staff (+non DSTG)", ($usersenabled | where { ...
+ ~~~
Unexpected token 'non' in expression or statement.

Not all parse errors were reported. Correct the reported errors and try again.
User avatar
Lembasts
Posts: 405
Last visit: Wed Mar 20, 2024 1:40 pm
Has voted: 1 time
Been upvoted: 1 time

Re: 161 compile no longer working

Post by Lembasts »

When I did an export to file, these are lines 10494 to 10504:
try
{
Set-ADAccountPassword –Identity $textboxUser.Tag.objectguid -Reset -NewPassword (ConvertTo-SecureString -AsPlainText "$($textboxpassword.text)" –Force)
Set-ADUser -Identity $textboxUser.Tag.objectguid -ChangePasswordAtLogon $true
}
catch
{
Write-ErrorLogs $_ "Cannot apply password to account [$($textboxUser.Tag.name)]"
$errorprovider1.SetError($buttonApply, 'Error in applying password information')
return
}
if that helps.
User avatar
Alexander Riedel
Posts: 8479
Last visit: Thu Mar 28, 2024 9:29 am
Answers: 19
Been upvoted: 37 times

Re: 161 compile no longer working

Post by Alexander Riedel »

The encoding is shown on the status bar. Clicking on it opens a menu that allows to change encoding.
PrimalScript and PowerShell Studio can resolve, include that is, any dot sourced files into the packaged executable.
Obviously if the encoding of dot sourced files and the main file differs, it can create problems. Hence my asking.

Neither 161, nor any previous build, will parse your code and output the errors you see, only PowerShell itself will ever parse your code and that is also where these error messages come from.
If you look at "vertTo-SecureString -AsPlainText "$($textboxpassword.text)" –Force" it would seem there is some problem in this section.
According to the code snippet that should be - (minus) as in -Force but is probably some other character.
I suggest to manually delete that character and replace with a proper '-' character.
It seems you pasted the code and when I look at the post above, the dash in front of 'Force' is visible longer than the one in front of 'AsPlainText' (at least on my screen)

I am at this time not certain why this has not caused a problem before, assuming that was there before, but it nonetheless appears not to be a proper parameter character.
Which leads me back to the encoding question. This is one thing we changed slightly to address another issue and maybe there was a conversion that previously fixed that problem without alerting to it.

I have not tested that yet, but it is quite possible that PowerShell itself has added code that corrects such characters when you run it as a script.
Alexander Riedel
SAPIEN Technologies, Inc.
User avatar
Lembasts
Posts: 405
Last visit: Wed Mar 20, 2024 1:40 pm
Has voted: 1 time
Been upvoted: 1 time

Re: 161 compile no longer working

Post by Lembasts »

...and if you were wondering - I did a command line compile under 160 and it worked fine - no parsing errors.
User avatar
Alexander Riedel
Posts: 8479
Last visit: Thu Mar 28, 2024 9:29 am
Answers: 19
Been upvoted: 37 times

Re: 161 compile no longer working

Post by Alexander Riedel »

I wasn't really wondering :D I was pretty sure that was the case.
Alexander Riedel
SAPIEN Technologies, Inc.
User avatar
Lembasts
Posts: 405
Last visit: Wed Mar 20, 2024 1:40 pm
Has voted: 1 time
Been upvoted: 1 time

Re: 161 compile no longer working

Post by Lembasts »

Very interesting. Obviously got away with it in the past.
The encoding is UTF-8-BOM.
I replaced the hyphen in front of the Force and Identity and compiled it and it worked fine!'
By the way I did a hex dump of the two characters:

- 0x2D 45
– 0x2013 8211

The first one is a normal hyphen and the second one is what was originally in front of Force - HTH

What should the normal encoding be? Should it be ASCII? I have no idea about those things.
And is there any way to search for non standard characters which is apparently what this Force 'hyphen' was?

Thanks for your efforts
Cheers
David
User avatar
Lembasts
Posts: 405
Last visit: Wed Mar 20, 2024 1:40 pm
Has voted: 1 time
Been upvoted: 1 time

Re: 161 compile no longer working

Post by Lembasts »

So I noticed that 160 doesnt have UTF-8-BOM. So I suspect that maybe my encoding prior to 161 was just UTF-8 and when 161 was installed it changed the encoding automatically to UTF-8-BOM which caused it to fail?
User avatar
Lembasts
Posts: 405
Last visit: Wed Mar 20, 2024 1:40 pm
Has voted: 1 time
Been upvoted: 1 time

Re: 161 compile no longer working

Post by Lembasts »

And I also noticed that a few fancy fonts that I was using, like old english, no longer displayed.
I'm thinking that the fact it appeared to change UTF-8 to UTF-8-BOM automatically after installing 161 was a bad move.
User avatar
Lembasts
Posts: 405
Last visit: Wed Mar 20, 2024 1:40 pm
Has voted: 1 time
Been upvoted: 1 time

Re: 161 compile no longer working

Post by Lembasts »

So Im going through and manually changing dozens of psf file encoding from UTF-8-BOM back to UTF-8.
I have some common files used in various projects.
What I noticed was that when I changed one of the common files to UTF-8, and then opened that same file in another project, the encoding said Windows-1252.
This topic is 4 years and 11 months old and has exceeded the time allowed for comments. Please begin a new topic or use the search feature to find a similar but newer topic.