I'm new to the Arduino scene and was wondering how I would get my sketch to call or interface with windows. For instance if I create a circuit with two buttons how would I use those buttons to call the left and right windows functions?
Is this even possible?(of course it is, its Arduino but how?!)
Thanks in advance. If anyone wants to see my sketch or anything just ask :/ its nothing exciting. plus I'm not sure it will really be needed?
For anyone looking for anything similar I found the necessary tutorials and libraries here: http://arduino.cc/en/Reference/MouseKeyboard
Related
I am using Qt Creator C++. I want to see these two pictures after each other every 3 seconds. But according to my code, it shows just the last image on the screen. Does anybody have any idea what I am doing wrong?
You shall use QElapsedTimer() and implement a slot which you shall then connect to QElapsedTimer's signal that is emitted after desired time. See Qt help for more information on that.
In the slot, you shall implement your logic of showing the images.
I think that exec(); is the moment where program starts, so you have to change pictures after that. I Would pastle this code inside youre main class, or inside some other function (for example button slot).
I am just beginning to learn about accessbility specifically in relation to JAWS - so newbie alert!
I am looking to modify an old vb6 app which has a form with a 3 column flexgrid. There is a custom edit box which is overlaid on the form for editing in the right most column. On row change, ideally JAWS needs to read the contents of the 2 leftmost columns on that row.
I am wondering how best to implement this?
I have seen possible solutions of loading into a text file and shelling out to JAWS on a row-change type event. This seems a bit heavy but maybe it is a good solution.
I have also read about the IAccessible interface. This sounds like a good solution to me, but I don't know if it'd give me what I was after ie whether JAWS uses this interface to get its info.
I would be grateful if someone could advise me/steer me in the 'right' direction about the way I should be thinking about this.
Visual Basic 6 is unsupported by Microsoft many (12+) years ago. It doesn't have any easy way to incorporate MS Active Accessibility (MSAA), the previous versions were missing support in many of the default graphic widgets, and many controls did and do not have keyboard access.
Don't use it is the best answer, but not to your question. If you must continue, you'll have to look at the MSAA route (you are headed in the right direction with IAccessible interface)
Originally, I wanted to ask how to create user interfaces with cocoa programmatically, i.e. without using interface builder. But it seems that someone else has already asked this question and the answers didn't help me.
So I'll ask a different question, that I hope will indirectly help me answer the previous question. Here it is:
(QUESTION_START)
How do I create an Objective C class that is equivalent in functionality with the BoxLayout class in Java? (Just click the link, the image on that page says everything you need to know about BoxLayout.)
(QUESTION_END)
Any help in the right direction will be appreciated!
There are a few sub tasks that are connected with the question, e.g.
"How do I ask a user interface element (e.g. a button) how large it wants to be" (before it has been drawn to the screen). To draw it on the screen you have to already know its size, don't you? Obviously, the interface builder application has figured out a way to do this.
I know that many Cocoa developers think it's a stupid idea to even try what I want to do. Let me tell you: I know the reasoning behind that opinion. Right now, laying out controls without interface builder sucks, because there is nothing that comes even close to a layout manager in cocoa. But if you think my question is stupid, please DONT answer. The whole internet is full of explanations why you would never want to create UIs with code in cocoa.
Thanks!
Answering your first question is kind of difficult and fairly involved, so I'm going to dive into your subquestion first:
How do I ask a user interface element (e.g. a button) how large it wants to be?
When you create a UI element, you tell it how big it should be (as well as where it should be) via its initWithFrame: constructor; or you can set its frame later via its setFrame: method. It will then draw itself into that space. You can get an element's frame via its frame method.
With that in mind, a BoxLayout class would, hypothetically, be a controller of some sort in which you could add UI elements, and then the BoxLayout controller would arrange them in a grid (or whatever) on an NSView of some sort.
I know you weren't looking for answers that questions motives, but given the complexity of a BoxLayout class vs. laying out the interface in IB, it seems relevant to ask why you want to do this.
I am writing an app with raw windows API (opensource Win32++) where I have a ListView.
The problem I have now is that whenever an item in the ListView is clicked, the system/app will generate a warning tone/sound "ding". Furthermore, I noticed I cannot get the LVN_ITEMACTIVATE through item-dbl-click or item-keypress-enter, which would normally work if this problem had not occur.
Would anyone have any idea how this might be happening?
I believe there is nothing wrong with Win32++, it just could be one of the things I do is causing this. But my program has become quite big to dissect plus I have no idea where to start looking.
Thanks.
PS: I had my computer muted for the longest time, hence, I don't know when this started eventhough I had the listview since a long time ago. T_T
Start looking with a tool that can show you the Windows messages that the control generates and receives. Like Microsoft's Spy++. Compare it with a working list view to have an idea what might be amiss. Also check the parent window. I haven't otherwise heard of listviews that dingaling, the LVN_ACTIVATEITEM should fire the first WM_LBUTTONDOWN, no double-click necessary.
I'm new to Objective-C, Cocoa, Xcode and Interface Builder. I've got some C background in the past, as well as a fair amount of RealBASIC experience.
I'm working through Mark and LaMarche's iPhone 3 Dev book and I'm really just sort of stunned about how tedious some things are. Maybe someone can shed some light on this for me. My question really is, why does the process for seemingly simple actions involve such a complicated number of steps? Is there a benefit to the complexity which I'll come to love later? Or is it just a brute fact that is unavoidable?
For example, in RealBASIC, if I want a slider's value displayed in a text box, I simply add:
myTextBox.text = mySlider.value
to the slider's Changed event. I can program this in well under 1 minute.
In Xcode/Interface Builder, I have to physically type a declaration for both the text box and the slider, then type a property/outlet declaration for each as well, then create a method declaration and implementation for the ValueChanged even, then set up a (relatively) complicated typecast of the slider's integer value into an NSString using initWithFormat. I then have to return to Interface Builder to link up the controls with the control and method outlets I typed in. I don't see how this can be done in much less than 10 minutes. Maybe 5.
So, what's the benefit of this? Why doesn't Interface Builder automatically create, or at least suggest, control declarations and #property statements, as well as method declarations and implementations? Why can't double-clicking a slider in IB offer you a list of events and offer to automatically insert a skeleton method into your .h and .m file? And why does IB even have to be a separate application?
I'm willing to accept that some of this is my unfamiliarity with all things Xcode, but is this really as efficient as the development environment can be?
My apologies if this is a dead-horse, flame-bait topic with opposing sides on full aggro. If so, please just say "yes, that it is" and move on.
Thanks,
-Rob
A lot of the reasons behind the way IB works will become more clear as you get used to the MVC paradigm.
Once you start using Cocoa Bindings, which update your model when the UI changes and vice versa, you should see an enormous productivity improvement.
I too used to think that Xcode and Interface Builder were unnecessarily complicated, until I worked through a book on both (specifically, Beginning iPhone Development: Exploring the iPhone SDK).
If you're serious about working with Xcode and Interface Builder and are as confused as I was when I started, I highly recommend picking up a book like the one I used. Granted, that was for iPhone development, but I think there is another book by the same publisher (or author) that is straight Mac programming.
Once you work through it and understand what is going on behind the scenes it starts to make a lot more sense. In some ways I prefer IB to things like Expression Blend or XAML for WPF programming in .NET.
Give a book a try and see if it helps :-)
Good luck!