-
Notifications
You must be signed in to change notification settings - Fork 403
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Resolve worksheet ArgumentCompleter Fixes:#1590 #1591
Conversation
hI @jhoneill, wanted to get your thoughts on this. - Thank you |
Not sure what's happened with the readonly parameter on open package which is the root cause if the issue. This looks like it will work and Get-ExcelSheetInfo has a little less overhead. So LGTM - without testing it for myself. |
@jhoneill I saw the @pbossman Do you have the script that shows the issue? I was answering a question within the last week and the completer "seemed" to be working. With |
To start: I discovered the issue by trying to tab-complete the worksheet names of a known file, I even tried a sample.xlsx file
which then shows the current folder items, not the sheet names Per your feedback, I added some code to catch the error explicitly and $xlPath = $fakeBoundParameter['Path']
if (Test-Path -Path $xlPath) {
Try {
$xlpkg = Open-ExcelPackage -ReadOnly -Path $xlPath
} catch {
Write-Host "Caught Error" -ForegroundColor Yellow
}
$WorksheetNames = $xlPkg.Workbook.Worksheets.Name
Close-ExcelPackage -nosave -ExcelPackage $xlpkg My guess is that this non-terminating behavior is internal to PowerShell ArgumentCompleter logic. A terminating error would create some interesting user behavior. You can reproduce the weird behavior be adding a completer into your current scope. Register-ArgumentCompleter -CommandName Import-Excel -ParameterName WorksheetName -ScriptBlock {
param($commandName, $parameterName, $wordToComplete, $commandAst, $fakeBoundParameter)
$xlPath = $fakeBoundParameter['Path']
Write-Host "Trying" -ForegroundColor Cyan
if (Test-Path -Path $xlPath) {
Try {
$xlpkg = Open-ExcelPackage -ReadOnly -Path $xlPath
} catch {
Write-Host "Caught Error" -ForegroundColor Cyan
}
$WorksheetNames = $xlPkg.Workbook.Worksheets.Name
Close-ExcelPackage -nosave -ExcelPackage $xlpkg
$WorksheetNames.where( { $_ -like "*$wordToComplete*" }) | foreach-object {
New-Object -TypeName System.Management.Automation.CompletionResult -ArgumentList "'$_'",
$_ , ([System.Management.Automation.CompletionResultType]::ParameterValue) , $_
}
}
} In summary: I defer to brighter minds As I've shown, the error can be explicitly caught\thrown, but to what end? |
Thanks @pbossman for checking that out. Fixing the feature would be great. More troubling is that Did a I look at your PR and take if for a spin |
I guess one anecdotal test should be enough :-D Funny, the @jhoneill Do any of your writeups on completers etc have an example of unit testing something like this? Guess it may be simple. The function body only uses the function WorksheetArgumentCompleter {
param($commandName, $parameterName, $wordToComplete, $commandAst, $fakeBoundParameter)
} |
Thanks Phil for the drill down and the fix. I've got a couple PRs still in review I want to include, so I'll publish this soon. |
This will update the argument completer for
Import-Excel
This change will use
Get-ExcelSheetInfo
instead ofOpen-ExcelPackage
to get the worksheet names