Is it possible to use Console.Write to place a single character at the very bottom right of a typical 80x25 console, without having the console scroll the row up? This is the code that I'm using...
Imports System
Console.SetCursorPosition(Console.WindowWidth-1, Console.WindowHeight-1)
Console.Write("x")
This is not working like I would like it to. Any suggestions or alternatives? I've tested that SetCursorPosition does use a 0,0 coordinate system, already. Using the WindowWidth-1/Height-1 should put me in the lower right corner of the screen... which it does, but then Console.Write is putting the "x" down and continuing on to the next line.
You can try moving the buffer area. For example:
Console.WriteLine("Top")
Console.SetCursorPosition(Console.WindowWidth - 1, Console.WindowHeight - 1)
Console.Write("x")
Console.MoveBufferArea(0, 0, 80, 25, 0, 1)
Console.ReadLine()
The problem is that whenever you write to the last location in a particular line, the console always moves you to the next line. The closest thing you can do is write to the second last location:
Console.CursorLeft = Console.WindowWidth - 1;
Console.Write("X");
I solved it in a dirty but functional way.
Console.SetCursorPosition(79, 24); //last pos
Console.BufferWidth++;
Console.Write("x");
Console.BufferWidth--;
Console.ReadKey();
the side of the box does flicker a millisecond, but I don't think anyone will ever notice :)
Related
I have a Iconic variable BackWallBoundaryLineXLD
It containts 2 points and the line connecting them.
I would need to move this line upwards 40 pixels, so basically change the row coordinate of the line to Currentvalue-40.
Is there a simple and clean way to do it, or do I have to extract the points first, edit them and then draw a new line?
Try
hom_mat2d_identity (HomMat2DIdentity)
hom_mat2d_translate (HomMat2DIdentity, -40, 0, HomMat2DTranslate)
affine_trans_contour_xld (BackWallBoundaryLineXLD, BackWallBoundaryLineXLDTranslated, HomMat2DTranslate)
Try using affine_trans_contour_xld(). You will have to setup a HomMat3D first that specifies your 40pixel translation.
I am trying to make a prompt for the user to select from the figure (plot).
When I run it with the code below, the prompt doesnt display until i click on the figure, after which the prompt displays and the code continues. In fact, no call to printf (or disp) that is called before the ginput call displays until i select the figure.
printf("Select part\n"); % (disp also doesnt work properly)
[xinput,yinput] = ginput(1);
The purpose of the prompt is to alert the user to move to the figure, so naturally it needs to display before selecting the figure.
I can add an extra redundant input call between the two which forces the printf to display in the console. eg input("Press Enter"). but this is an inconvenient solution.
Strangely, if you run just the code above it does work normally. But when running in the remainder of the program it displays the issue. So it may be a difficult one to debug. Also, running it one line at a time in the full code using the debugger works properly, displaying the prompt before selecting the figure.
Just to add to the confusion. When running this part of the program in a loop, the first instance doesnt display the prompt correctly, but every other instance it works.
Thanks
EDIT:
The following code reliably fails (for me) in the same way my full program fails; (edited again to simplify)
figure(1);
input_test = input("press 1: ");
switch input_test
case 1
while true
clc;
printf("Left click to get coords or right click to finish\n");
[xinput,yinput,mouse_button] = ginput(1)
if mouse_button == 3
break
endif
endwhile
endswitch
It appears it has something to do with the line;
input_test = input("press 1: ");
If I replace this with
input_test = 1;
it works properly.
I dont know what is the reason for this, and I cannot remove the input request from this location.
Thanks Roger, you were correct, I did find a solution.
Using
fflush(stdout)
before the 'ginput' call solves the problem.
Found this in the 'input' help;
"Because there may be output waiting to be displayed by the pager,
it is a good idea to always call 'fflush (stdout)' before calling
'input'. This will ensure that all pending output is written to
the screen before your prompt."
IntelliJ pro comes with an embedded SQL editor.
Sometimes, I type a wrong request and the database returns an error and the corresponding SQL position.
Example :
[2017-01-02 16:32:35] [42P01] ERROR: missing FROM-clause entry for table "customer"
Position : 516
Problem : for readability reasons, the request is written on multiple lines, making it harder to find the position 516.
Up to now, the only solution I got is to delete the \n characters in order to have the request on only one line then navigate to the 516th column.
But I guess there is a better way, like a fancy keyboard shortcut?
It's been a while you asked but I'll answer anyway to help others:
Download "Character Position" plug-in from here:
https://plugins.jetbrains.com/plugin/10334-character-position
Install plugin & Restart IntelliJ
Character position will be shown in the bottom-left corner of the editor.
In my case I press F2 and cursor go there.
The current caret position (line number and offset) is displayed in the Status Bar. You can click it to open the Go To Line dialog box.
Change the second number to the needed position of your character and will be navigated directly.
I have an Xbox One controller setup with Unity3d, and when I try to use the RT button nothing happens.
With the following setup, the RB button works fine:
I have looked at this but setting that up doesn't make sense to me. I have tried 3rd Axis 0_10th and I have tried 3rd Axis 0_1 but those are not valid. What is the proper settings for this to work?
To the get the result I was looking for, I needed to set it up the following way:
Then to get the button to work we need to use:
if(Mathf.Round(Input.GetAxisRaw("Fire1")) < 0){
// Firing code here
}
instead of:
if(Input.GetButton("Fire1")){
// Firing code here
}
Yes, thanks for posting. I was having the same problem using a 360 wired controller in Unity3d. It looks like the Left and Right triggers now both use the 3rd axis (Joystick) with the Left generating positive (0 to +1) values and the Right trigger generating negative (0 to -1) values. This differs from all the documentation I was finding.
Using Rebol/View 2.7.7, I'm trying to create a card game based on Nick's Rebol tutorial at: http://re-bol.com/rebol.html#section-10.18. What I want to do though is read the cards from the binary file Nick created, discard some of the data, and use it to layout a tableau of cards, 4 rows of 3 columns, with the 2 center card locations not used.
Here's my code:
protect-system
random/seed now
do %cards.r ;--include the binary card data
the-tableau: [
size 320x480 backdrop 0.170.0
style tabstyle image 80x100 teal
style holdplace box 80x100 coal
across
at 30x20 tc1: tabstyle
tc2: tabstyle
tc3: tabstyle return
at 30x130 tc4: tabstyle
tc100: holdplace
tc5: tabstyle return
at 30x240 tc6: tabstyle
tc200: holdplace
tc7: tabstyle return
at 30x350 tc8: tabstyle
tc9: tabstyle
tc10: tabstyle
]
lc: copy []
lc: [tc1 tc2 tc3 tc4 tc5 tc6 tc7 tc8 tc9 tc10]
deck-cards: copy [] ; The deck holds all of the cards from the binary file
deck-cards-num: copy []
deck-cards-color: copy []
lay: layout the-tableau
foreach [card label num color pos] cards [
dimg: load to-binary decompress (card)
append deck-cards dimg ;feel movestyle
throw-away-label: label
append deck-cards-num num
append deck-cards-color color
throw-away-pos: pos
]
random-card: does [pick deck-cards random length? deck-cards]
foreach c lc [set-face get c deck-cards]
view lay
do-events
But this doesn't show the cards at all. I'm not even sure it's reading the correctly? Where is the problem?
Actually you didn't use the random-card function in your for loop at the end... :-)
foreach c lc [get c set-face get c random-card ]
You note that you are not sure if data was loaded correctly...
here is a simple way to find out... just print/probe the TYPE? of that data
dimg: load to-binary decompress (card)
probe type? dimg
In this case it will print out image! in the console... so yep... that's working. :-)
As an added little detail, I noticed you didn't compensate your random for the "back face" image in the card data (which is at its end), so the random-card function should be fixed like so:
random-card: does [pick deck-cards random (length? deck-cards) - 1] ; - 1 since we don't want the back face to be picked.
You only need 'do-events if the event loop is not started.
View/new does not start the event loop .. but View does
I'm not addressing your actual problem though :(
to make the do-events note clear, I added a little answer here so I can add some inline code....
here is an example where you'd want your do-events to be used.
view/new lay ; display the interface right now. (with no cards)
random-card: does [pick deck-cards random (length? deck-cards) - 1] ; - 1 since we don't want the back face to be picked.
; deal cards with a half second delay.
foreach c lc [f: get c set-face get c random-card wait 0.5]
do-events
here, any code you put after 'DO-EVENTS will be executed once all view windows have closed.
which can be things like tmp file cleanup, save on exit, "save changes" dialogs, etc.
additional note:
While building graphics code, its a good habit to place this at the very start of you application:
print " "
It will open up the console, and then any view windows will show up in front of it.
When ready to share, just comment the line and remove any print statements in your code.
this is useful for 3 things:
1) Its usually highly annoying when the console always pops-up over your application while its tracing (print/probe/etc) some stuff after your window opens.
2) This also has the more useful side-effect of showing you if your application quit correctly since the console will ALSO quit when all waits have terminated correctly.
In your original example, if you add the above print, then you'll see that the console never closes, so this means the application is still running with no more application windows listening to events.
3) It also has the advantage that you can terminate the graphic app directly by closing the console window. This effectively closes all windows and waits immediately and shortcuts any "on application quit" code you might have (code after do-events).