According to MS the following is possible
myTextBox.Control Source = [Firstname] & " " & [LastName]
Control Source set to this '=[FirstName] & " " & [LastName]'
My testing shows this is correct in a small test DB.
However in my production DB this is failing. Both fields are Short/Text so I'm not sure what is going on here.
I get #Type! displayed instead.
Also these variations produce these results:
[LastName] ! This works
=[LastName] ! This works
=" " & [LastName] ! This works
[FirstName] ! This works
=" " & [FirstName] ! This Doesn't work, displays #Type!
=[FirstName] ! This Doesn't work, displays #Error
So something is strange with my FirstName field!
Any ideas what I should check or look at!
Turned out to be the naming of the TextBox control.
It was called FirstName. When I changed it to FullName it behaved as expected.
However I'm not sure why the name made any difference!
Maybe there was some underlying connection between the textbox and the field when the names coincide???
Related
As the title says i am trying to press the "dash" button on my keyboard, however i'm not sure what to use since every name that i have tried comes back with an error or a different key gets pressed; here is what i tried:
"-": Error
"dash": Error
"minus": "'" gets pressed
"mdash": Error
"ndash": Error
And unfortunately i haven't been able to find any documentation regarding the names, only for the methods: https://douile.com/logitech-toggle-keys/APIDocs.pdf
There are 3 equivalent ways to simulate pressing minus key:
PressAndReleaseKey("minus") -- symbolic name
PressAndReleaseKey(0x00C) -- scancode
PressAndReleaseHidKey(0x2D) -- HID code
I am working on a pexpect script that is running populating an output file name and then a prompt for the file's parameters.
The program that the script runs asks for Device: then Parameters: always on the same line.... so if the file path-name that is entered for Device is long, sometimes the Parameters prompt wraps to the next line.
My code looks like..
child.expect_exact('Device:')
child.sendline('/umcfiles/ftp_dir/ftp_peoplesoft/discount/AES_DISCOUNT_15010.TXT')
child.expect_exact('Parameters:')
This times out.. and here is what is in child.before
' /umcfiles/ftp_dir/ftp_peoplesoft/discount/AES_DISCOUNT_15010.TXT Param\r\neters: "RWSN" => '
so the expect fails... (a child.expect('Parameters:') also fails)
How can I ignore the \r\n if it is there, because depending on the length of the path/filename I am using it may not be there at all, or be in a different position.
Thanks!
Actually... I found a way to calculate how much is left on the given line, and dynamically set my expect to how much of the Parameter prompt should be visible... seems to be working
#look for end of line and fix how much of 'Parameters:' we look for in pexpect
dlen = 80-len('Device: /umcfiles/ftp_dir/ftp_peoplesoft/discount/AES_DISCOUNT_15010.TXT')
pstr='Parameters:'
if dlen > len(pstr):
dlen=len(pstr)
else:
dlen=dlen-3 #remove the /r/n
child.expect(pstr[0:dlen])
Totally lacking intuition here.
First i thought i only happens when copying and pasting code from editor. Unfortunately it's more common. Only thing I am doing is trying to insert more code somewhere in the middle of current input or modifying it.
Expected behavior:
Modify input without side effects.
What actually happens:
VERY OFTEN when modifying input it gets messed up.
If that happens every key press will copy and insert current input alongside with pressed character.
Vital notes:
Encoding is set to UTF-8 in terminal(s)
Issue persists on different emulators ( Terminator, gnome-terminal )
Issue persists when using different Ruby runtime console ( IRB, Pry )
Issue appears to be related to Ruby runtime, NOT Linux shell (i guess...)
Issue appears since:
Since system install. Didn't appear on my MacBook Air
System:
ArchLinux, although coworker reported same thing happens on his MacBook Pro.
How to reproduce (works for me):
Open rails console
Type example code: Shift.where(name: "som").where(name: "dom").where(name: "pom")
Navigate cursor to modify first where statement.
Change "som" to "SOM"
Should see it break
Press random key repeatedly to see it break even more.
Images:
Good input
Now i will navigate to first where statement to change "som" to uppercase "SOM"
I basically navigated my cursor and pressed SHIFT+S, SHIFT+O, SHIFT+M
Hope it's clear enough :-)
Thank you!
EDIT 1:
Tried using zsh instead of bash, didn't help
Disabled spring gem, didn't help
EDIT 2:
Folks on reddit suggested that i should check if there are any Ruby readline warnings eg. "Readline is not installed". None of them appear anywhere. Also reinstalled ruby 2.4.1, seems like it's not the problem in my case.
EDIT 3:
I cannot reproduce the issue in a different Rails project.
Issue appears on Rails 5.1.1, meanwhile 5.0.3 works flawlessly.
Is it possible that Rails itself (or rather one of its gems) can be the cause?
I had a very similar issue, and I boiled it down to my coloring.
I had the following in my IRBRC:
class String
def _colorize(color_code)
"\e[#{color_code}m#{self}\e[0m"
end
def red
_colorize(31)
end
def yellow
_colorize(33)
end
end
IRB.conf[:PROMPT][:MY_PROMPT] = {
:AUTO_INDENT => true, # enables auto-indent mode
:PROMPT_I => "[ME]".red + " > ".yellow, # normal prompt
:PROMPT_S => "[ME]".red + " ".yellow, # prompt for continuated strings
:PROMPT_C => "[ME]".red + " * ".yellow, # prompt for continuated statement
:RETURN => "[ME]".red + "=> ".yellow + "%s\n".red # format to return value
}
IRB.conf[:PROMPT_MODE] = :MY_PROMPT
And when I removed the .red and .yellow, everything was just fine.
I think it's because my coloring characters like \e[31m was getting counted as a length 5 characters instead of 0 characters.
My solution was to remove my coloring for the time being. Hopefully someone will come up with a better solution than that.
I am trying to run some protractor tests in Safari (they run fine in Chrome).
The problem seems to be that the return key is not working correctly in sendKeys() method.
The value is being not send ( - is undefined)
Here is what I did on the input object:
input.sendKeys(value + '\n');
Also, I tried
input.sendKeys(value + protractor.Key.ENTER);
But getting the same results.
According to the webdriverjs doc, the correct syntax seems to be:
input.sendKeys(value, protractor.Key.ENTER);
Have you also tried to send the text and the enter key separately:
input.sendKeys(value);
input.sendKeys(protractor.Key.ENTER);
You should be able to do something like this:
browser.actions().sendKeys(protractor.Key.ENTER).perform();
If you want to use a combination of keys in protractor, try this (for example SHIFT + TAB):
browser.actions().sendKeys(protractor.Key.SHIFT, protractor.Key.TAB).perform();
I've got a script that I'm running where I declare the path I'm using, then define my source files as all the child items in that path.
$htmPath = "c:\users\x\desktop\cgc\ht"
$srcfiles = Get-ChildItem $htmPath -filter "*.htm*"
I've run this successfully in the past, but this morning I started getting the following error:
You must provide a value expression on the right-hand side of the '*' operator.
At C:\users\x\desktop\cgc\CGC002.PS1:63 char:46
+ $srcfiles = Get-ChildItem $htmPath -filter "* <<<< .htm*"
+ CategoryInfo : ParserError: (:) [], ParseException
+ FullyQualifiedErrorId : ExpectedValueExpression
To me, it appears that this error is being thrown because the script is interpreting my wildcard as a multiplication, and wants the value on the right side necessary to complete the operation. Am I interpreting it properly? If that is indeed the case, how do I make sure that my wildcard is interpreted as a widlcard?
I did find this link, but it's a different enough scenario with different enough code that I'm not sure it applies. However, I did find this comment in the thread interesting:
Try putting the *, at the start of the property list instead of the end. I think it's just getting confused. It's mainly your formatting.
...so I exited PS, warm-booted, the usual did-you-try-turning-it-off-and-back-on-again confusion resetters, and still, the same error.
Maybe I have a typo somewhere that I can't see?
Or, if I'm completely missing the interpretation of the error...school me.
Ended up being a single double-quote off the right side of my text editor. Color coded syntax checking helped me verify that it was a mismatched quote issue...thinking to scroll to the right to FIND the " took a lot more time than it should have. Facepalm.
Thanks to #Richard who offered up this suggestion.