Using a "Dialog"-box (so a .top file too), how can i turn NAO's brain leds on? I know that you can call an output like "$turnledson=1" and connect it to "Set Leds"-box and turn the leds on that way, but what about a command that can activate them without the need of another box from choregraphe? Something like "^start(animations/LEDs/BrainLedsOn)", if it exists.
There is no direct LED commands in QiChat.
However, if in your app myapp you create a new behavior called brain/anim1 (with a box in it!), and you make sure it is exposed (checked in the project properties), you can use ^start(myapp/brain/anim1) to start your Choregraphe behavior within your QiChat code.
But as you can see, you need to use a Choregraphe box somewhere in the end.
Related
I'm not able with any youtube tutorial and blogs to make a joystick movement for my topdown 2d game on godot
as I said, follow step by step several tutorials on the internet / youtube and I couldn't get my joystick for my topdown2d game
You should not need any special code to use a joystick with Godot. Run of the mill code like this should work:
extends KinematicBody2D
var speed := 500.0
func _physics_process(_delta:float) -> void:
var velocity := Vector2(
Input.get_axis("left", "right"),
Input.get_axis("forward", "backward")
) * speed
move_and_slide(velocity)
Either that or something similar you might find in most tutorials. Which probably use "ui_left", "ui_right", "ui_up" and "ui_down" which are pre-defined actions. And yes, there are also pre-defined joystick inputs for those actions, but they might not be correct for your device.
Before configuring the actions, make sure the device is recognized by the operating system (you might need to install/update drivers). You might also want to run a diagnostic tool to check if it can send input.
Now, configure the actions on Project Settings -> Input Map. You can add new actions or modify the pre-existing ones. Once you have the action defined, click on the "+" icon on the right, and there you will find the "Joy Button" and "Joy Axis" options which will let you configure the joystick input for the action. Double click will allow you to modify the existing ones.
There is always the chance you configured the wrong input on the wrong action. You could figure it out by trial an error or with the help of a diagnostic tool.
If your device works, the configuration is correct and it still does not work. We could be talking of a compatibility issue. You might want to report a bug on github.
I can't help you further without knowing what did you try and the results you got.
In the program I am writing, I created an OLEObject to connect to a webpage in Internet Explorer that results in an automatic pop-up prompting me for my credentials.
I've been trying to avoid having to switch tabs and manually click OK by instead sending the "ENTER" keystroke to the window using Sybase's keybd_event subroutine : http://www.sybase.com/detail?id=47760
I declared the subroutine as an External Global Function and added the code where it was needed. The interesting thing is is that the program successfully presses the OK button in the pop-up window when I step through each line in debugger mode, but it fails to do so when I compile and run it.
Could anyone give any suggestions as to how to fix this? Or perhaps propose an alternative method entirely?
Thanks!
I'm not clear if you are using the built in Inet, InternetResult, InternetData objects in PB, but if you are I think you use the PostURL to do something like that. Then use the GetUrl to read a webpage into the Inet object. It's been a long time since I've used this, apologize if this leads you down the wrong path.
I'm using tmux window manager with OS X's terminal. I'd like to be able to use the key bindings to switch between tmux panes or split them instead of having to type out 'tmux select-pane' or 'tmux split-window' every single time. However, pressing CTRL and b together, which according to the man page is the default key binding, has no effect.
For example, the man page says I should be able to type CTRL and b (or, as it puts it, C-b) along with " to split the window. Pressing these keys together does nothing. None of the key bindings produce any effect in tmux.
I tried googling the issue and got back lots of results telling me to edit my ~/.tmux.conf file, but I don't have this file at all. It doesn't exist and was not created when I installed tmux using MacPorts, thus I cannot edit it to change the key bindings.
I can't find anyone who has had a similar problem, that of the key bindings not producing any effect at all. What am I doing wrong? Does the Macbook Pro keyboard simply not support key bindings? I'd appreciate it if someone could shed light on what my problem is.
Do simple commands work? Like C-b , to rename the window? If not maybe try using iTerm2?
I wrote a large complex C program around 20(!) years go. As far as I can recall it worked fine at the time in all respects - it was probably running on windows 95.
Now I need to use it again. Unfortunately the radio buttons in it do not appear to work properly any more (the ordinary push buttons are all behaving correctly). As I click on the radio buttons, I get some feedback that windows is acknowledging my click in as much as I see a dotted line appear around the button's text and the circle of the button goes grey for as long as my finger is on the button, but when I take my finger off I see that the selected button has not changed.
My suspicion is that I was perhaps getting away with some bad practice at the time which worked with windows 95 but no longer works on newer versions of windows, but I'm struggling work out what I did wrong. Any ideas?
EDIT: Its difficult to extract the relevant code because the message handling in this program was a tangled nightmare. Many buttons were created programatically at runtime and there were different message loops working when the program was in different modes of operation. The program was a customisable environment for running certain types of experiment. It even had its own built-in interpreted language! So I'm not expecting an answer like "you should have a comma instead of a semicolon at line 47", but perhaps something more like "I observed similar symptoms once in my program and it turned out to be ..... " .. or perhaps "the fact that the dotted rectangle is appearing means that process AAA has happened, but maybe step BBB has gone wrong".
EDIT: I've managed to extract some key code which my contain an error...
char *process_messages_one_at_a_time()
{
MSG msg;
int temp;
temp = PeekMessage(&msg,winh,0,0,PM_NOREMOVE);
if (temp)
{
GetMessage (&msg, NULL, 0, 0);
if (msg.message == WM_LBUTTONUP)
{
mouse_just_released_somewhere = TRUE;
}
TranslateMessage (&msg);
DispatchMessage (&msg);
}
if (button_command_waiting)
{
button_command_waiting = FALSE;
return (button_command_string);
}
else
{
return (NULL);
}
}
There are two simple things to check when using radio buttons. First is to make sure that each has the BS_AUTORADIOBUTTON property set. The second is to make sure that the first button in the tab order and the next control after the set of buttons (typically a group box) have the WS_GROUP property set, while the other buttons have it clear.
A few suggestions:
I'd try to use spy++ to monitor the messages in that dialog box, particularly to and from the radiobutton controls. I wonder if you'll see a BM_SETCHECK that your program is sending (ie, somewhere you're unchecking the button programatically).
Any chance your code ever checks the Windows version number? I've been burned a few times with an == where I should have used a >= to ensure version checking compatibility.
Do you sub-class any controls? I don't remember, but it seems to me there were a few ways sub-classing could go wrong (and the effects weren't immediately noticeable until newer versions of Windows rolled in).
Owner-drawing the control? It's really easy to for the owner-draw to not work with newer Windows GUI styles.
Working with old code like that, the memories come back to me in bits and pieces, rather than a flood, so it usually takes some time before it dawns on me what I was doing back then.
If you just want to get the program running to use it, might I suggest "compatibility mode".
http://www.howtogeek.com/howto/windows-vista/using-windows-vista-compatibility-mode/
However, if you have a larger, expected useful life of the software, you might want to consider rewriting it. Rewriting it is not anywhere near the complexity or work of the initial write because of a few factors:
Developing the requirements of a program is a substantial part of the required work in making a software package (the requirements are already done)
A lot of the code is already written and only parts may need to be slightly refactored in order to be updated
New library components may be more stable alternatives to parts of the existing codebase
You'll learn how to write current applications with current library facilities
You'll have an opportunity to comment or just generally refactor and cleanup the code (thus making it more maintainable for the anticipated, extended life)
The codebase will be more maintainable/compatible going forward for additional changes in both requirements and operating systems (both because it's updated and because you've had the opportunity to re-understand the entire codebase)
Hope that helps...
I'm working in a embarked application on linux that can be used with different PC hardware (displays specifically)
This application should set the environment for the highest allowed resolution (get by
the function XRRSizes from libXrandr).
The problem is: With some hardware, trying to set for the highest option creates a virtual desktop i.e. a desktop where the real resolution is smaller and you have to scroll w/ the mouse in the edges of the screen to access all of it.
Is there a way to detect within the Xlib (or one of it's siblings) that I am working with a virtual resolution (In other words, the re-size didn't go as expected) ?
Hints for a work around for this situation would also be appreciated...
Thanks
Read this: http://cgit.freedesktop.org/xorg/proto/randrproto/tree/randrproto.txt
You need to learn the difference between "screen", "output" and "crtc". You need to check the modes available for each of the outputs you want to use, and then properly set the modes you want on the CRTCs, associate the CRTCs with the outputs, and then make the screen size fit the values you set on each output.
Take a look at the xrandr source code for examples: http://cgit.freedesktop.org/xorg/app/xrandr/tree/xrandr.c