if keyboard_check('D')
{
x = x + 4
sprite_index = spr_playerRight
}
As soon as I start the game, the player sprite will start moving to the right. But, as you can see, that shouldn't be happening... right?
When I actually do press D, it does the (Else) portion of the little chunk.
Any idea why this is happening? I'm a bit new to this.
Edit: I was messing around a little and I swapped the code (the IF from the else) and I would not move at the start, but pressing any key would cause me to move.
Another Edit: The fact that the Else would apply any time the D key is not applied made me realize that (if this did work properly) the else on this would intrude on attempts to move other directions (Pressing any button will stop the movement)
Another Edit: I changed the keyboard_check to
keyboard_check(vk_right)
And it works perfectly fine. I believe this is simple a problem on how I declared the key... How do I declare keys properly?
According to the documentation it should be:
if keyboard_check(ord('D'))
Related
I have the following code with two dictionaries. I can see that when I iterate through DictForbidden even though it is empty the execution flow enters the loop so DictToAdd.remove(anInteger); is executed with
the old value of anInteger
var DictForbidden, DictToAdd : TDictionary<Integer,boolean>;
var anInteger: Integer;
DictForbidden := TDictionary<Integer,boolean>.Create;
DictToAdd := TDictionary<Integer,boolean>.Create;
anInteger := 1;
DictToAdd.Add(anInteger,true);
for anInteger in DictForbidden.Keys do
DictToAdd.remove(anInteger);
DictForbidden.Free;
DictToAdd.Free;
I am running Delphi 10.4 and I don't recall such a behavior in 10.3. I think back then if the dictionary was empty the loop was not entered. Do you know if this is something new on Delphi 10.4?, or maybe I am doing something wrong here?
regards, Carlos
In my 10.4.1 it doesn't enter the loop. But it may look like it does when you debug trace due to optimization made by the compiler. Try replacing the
DictToAdd.Remove
with a
writeln(anInteger) // if Console Application
ShowMessage(IntToStr(anInteger)) // if GUI Application
and see if anything is reported.
thank you very much for the quick help!
Actually you are right #Heartware. After the loop, DictToAdd still contains a 1. So basically there is no case here rather than putting a break point in the line DictToAdd.remove(anInteger); the execution is stopped and putting then the cursor above anInteger you see the value is 1 but stepping over the 1 is not being removed. When replacing the removal by a showmessage I observe the same thing the break point is reached but the showmessage is not executed.
Also noticed that when using a begin/end like this
for anInteger in DictForbidden.Keys do
begin
DictToAdd.remove(anInteger);
end;
the break point is not reached.
This is a little annoyance with the debugger caused by the fact that a loop of course produces some executable code - especially a for in loop that has calls to MoveNext and Current and some cleanup code for the enumerator after it completes.
This code has to go somewhere and often the line information being used by the debugger (aka "the blue dots") of that code overlap with actual code you wrote like in this case.
To illustrate this here is how the disassembly looks like when I put your code into a console application.
As you can see there are two breakpoints displayed here which belong to the same one breakpoint I placed in line 21. But the one that got hit is the one with the cleanup code which is responsible for destroying the enumerator. If you hit F7 and you compiled with debug dcus you will notice that it actually does not go into TDictionary.Remove but into TObject.Destroy.
Now the disassembly after placing the begin and end:
Again two breakpoints shown but this time I actually placed them both myself - and they are for different lines.
I am trying to display text in a HUD style semi-transparent window. I have got the code for the window all set up, but I have been scouring the documents for two days now and haven't come up with a way that works to actually display text in the window. Since I am using AppleScriptObjC in Script Debugger, and not Xcode, I'd rather do this programmatically and not have to switch to Xcode and use IB. (I did spend some time messing around with IB, but it is not very intuitive to be honest. So I thought I would check this form before going through the guides on how to get started using IB).
So I was given some advice to "create an NSTextField and add it to your window's contentView". So I have tried many different set ups of trying to init a NSTextField (And NSTextView), and I may have been able to get that part correct, but getting the text to actually display in the window has been a bigger challenge than I expected. I have included a code snippit of the code I am using to generate the window.
tell (NSWindow's alloc()'s ¬
initWithContentRect:{{theWidth, theHeight}, {640, 480}} ¬
styleMask:NSBorderlessWindowMask ¬
backing:NSBackingStoreBuffered ¬
defer:true)
setOpaque_(yes)
setAlphaValue_(0.5)
setBackgroundColor_(NSColor's grayColor())
setReleasedWhenClosed_(yes)
setExcludedFromWindowsMenu_(yes)
orderFrontRegardless()
delay 1
|close|()
end tell
My hope is to be able to get an NSText View in that Window in order to display some text in it. So far I haven't come close. The errors I generally get are about "unrecognized selector sent to instance". So it is pretty obvious that I am doing something wrong. I hope there is an easy way to accomplish this that I haven't yet come across.
It sounds like there isn't a target for some of the methods. In a tell statement, usually the target is implied, but sometimes AppleScript can't figure it out. You also don't get the newer method syntax, so I've had better luck just specifying the target for everything - also note that object properties can usually be set directly instead of using their setter method.
I can't tell from your snippet, but you also need to add the textView to the window's contentView, for example:
use AppleScript version "2.4" -- Yosemite (10.10) or later
use framework "Foundation"
use scripting additions
# create a text view
tell (current application's NSTextView's alloc's initWithFrame:{{20, 20}, {600, 440}})
set theTextView to it
end tell
# create a window
tell (current application's NSWindow's alloc()'s ¬
initWithContentRect:{{200, 600}, {640, 480}} ¬
styleMask:(current application's NSBorderlessWindowMask) ¬
backing:(current application's NSBackingStoreBuffered) ¬
defer:true)
set theWindow to it
set its opaque to true
set its alphaValue to 0.5
set its backgroundColor to (current application's NSColor's grayColor)
set its releasedWhenClosed to true
set its excludedFromWindowsMenu to true
end tell
theWindow's contentView's addSubview:theTextView
theTextView's setString:"this is a test"
theWindow's orderFrontRegardless()
delay 5
theWindow's |close|()
I am trying to find a strategy in the Vimperator-logic for opening a link to a new tab and switch to it immediately.
I guess this might be a TMTOWTDI.
My first approach would be to start off with a :command sequence. Unfortunately F - Follow hint in background tab - has no equivalent in the command mode. The best solution for me would be without any change in default behaviour whatsoever.
Another approach might be to combine the default F with switching to next tag gt. This would have to include to pass the parameter for F, say 10 for the tenth link of the document. Unfortunately F10gt does open the tenth link but without switching to the newly opened tab.
A third approach does come to mind when using focus elements: ;y10 yank the destination link, :tabopen + paste clipboard content.
Any ideas of what is doable and the easiest?
This functionality exists as a mode of the hint function. Pressing ;t
will produce the desired result. If you want to map it you can also access the javascript directly.
:js hints.show("t")
I am using the Camera to take pictures in an IOS app.
It works, the only issue I have is when I try to figure out how the user was holding the device when taking the picture.
It would be much better if I could display the images in a proper way, not upside down or rotated 90 degrees.
Looking for a solution leads me to the fact that I should use the imageOrientation of UIImage but in reality:
theImage.imageOrientation is always equal to UIImageOrientationUp
What am I missing?
I did various research and experiment but nothing changes.
I am not showing any more code at this point, for the simple reason, I do not know which part to show to help find the problem.
Since I was able to find a solution on my own. I put it here, in case it may be useful to someone else.
Looking at the value of the "imageOrientation" field on the saved image (like I was doing), indeed for some reason always shows up as UIImageOrientationUp.
On the other hand looking at it inside the imagePickerController:didFinishPickingMediaWithInfo: is much more meaningful.
After some more research and trials, I ended up with a method looking like that:
- (void)imagePickerController:(UIImagePickerController *)picker
didFinishPickingMediaWithInfo:(NSDictionary *)info
{
……
UIImage *image = [info objectForKey:UIImagePickerControllerEditedImage];
……
if ((image.imageOrientation==UIImageOrientationLeft)||
(image.imageOrientation==UIImageOrientationRight)||
(image.imageOrientation==UIImageOrientationDown)) {
UIGraphicsBeginImageContext(image.size);
[image drawAtPoint:CGPointMake(0.0, 0.0)];
image=UIGraphicsGetImageFromCurrentImageContext();
UIGraphicsEndImageContext();
}
NSData *mediaData = UIImagePNGRepresentation(image);
……
}
And then my picture shows properly oriented, when I want to use it later in my app.
I added a background color to the window of a well-running simple draw project and build succeeded. Then the fun began: runtime errors appeared in the console window. I found no help in Apple docs and Google. When the same happened in another draw project, I knew I had to ask for help.
Here's what happened each time I did a build & debug and stop -- runs 1) through 4). "continue" means I clicked the Continue icon. It kept on erring in no consistent order.
1)Program received signal:“EXC_BAD_ACCESS". spinning ball. paths OK.
continue. “EXC_BAD_ACCESS. spinning ball. paths disappear. background appears.
2)continue, 6 times. “EXC_BAD_ACCESS”. spinning ball. paths disappear. background appears.
3)immediately:
2012-12-26 09:53:18.265 bezier triangle[388:a0f] -[NSCFArray stroke]: unrecognized selector sent to instance 0x1005184f0
2012-12-26 09:53:18.268 bezier triangle[388:a0f] -[NSCFArray stroke]: unrecognized selector sent to instance 0x1005184f0
2012-12-26 09:53:37.846 bezier triangle[388:a0f] -[NSCFArray stroke]: unrecognized selector sent to instance 0x1005184f0
2012-12-26 09:53:37.847 bezier triangle[388:a0f] -[NSCFArray stroke]: unrecognized selector sent to instance 0x1005184f0
no continue icon. paths OK. no background.
4)continue, 6 times. “EXC_BAD_ACCESS”. spinning ball. no paths. no background.
The NSWindow class creates a couple of Bezier paths in initWithRect: and draws them in drawRect:. It ran well.
I got the setBackGround: code from Apple's Window Programming Guide and pasted it into the previously empty AppDelegate.
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
// Background color
[window setOpaque:NO]; // YES by default
NSColor *semiTransparentBlue =
[NSColor colorWithDeviceRed:0.0 green:0.0 blue:1.0 alpha:0.5];
[window setBackgroundColor:semiTransparentBlue];
window.backgroundColor = NSColor.blueColor;
}
Setting breakpoints showed that the runtime errors occur after this code finishes.
Thinking that the problems might have something to do with the timing of its execution, I moved this code to initWithRect and then into awakeFromNib. These didn't work. I wish I could find some example that shows how to implement this. All help will be appreciated.
No, setBackground: did not cause the runtime errors.
In the paths code, the paths weren't being allocated and inited properly, although the project ran correctly until the setBackground: code was added. Strange!
I'm sorry I didn't enclose the paths code in my question because it was too long.
I found my mistakes by starting a new project and building it up slowly, a piece at a time.