Re: NSPopover + Bindings + Validation = Weirdness
On 26 May 2014, at 01:04, Keary Suska wrote: > I am implementing an editing view in a popover, and discovered that > validations messages will cause exceptions because AppKit is broken in that > regard...anyway so I set "always use application modal alerts" and that seems > to work although the API is beeping somewhere after the alert is dismissed > and I can't seem to find out why. This only happens when tabbing out of the > field. I have a "commit" button that calls commitEditing and the validation > message appears and there is no beep when it is dismissed. Have you tried overriding : NSResponder - (void)presentError:(NSError *)error modalForWindow:(NSWindow *)aWindow delegate:(id)delegate didPresentSelector:(SEL)didPresentSelector contextInfo:(void *)contextInfo You can access the NSWindow instance at popoverObject.contentViewController.view.window;. It might be possible to work around the AppKit bug. > I suspect that the tab key event is somehow not being handled and is passed > up the responder chain to something that doesn't like it so beeps. This seems likely. You could try just handling this event yourself within the responder chain. I find that using XSViewController improves the whole NSView + responder chain experience. Jonathan ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Prevent NSColorWell gets textColor
Hi, I have several NSColorWells. One for the textColor, one for the guideColor, one for the pageBackgroundColor. If the pageBackgroundColor colorWell is active while I am editing a text in a NSTextView, the pageBackgroundColor colorWell gets the text color so the page background changes color. And this is wrong. How can I prevent that error? Regards -- Leonardo ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
EXC_BAD_ACCESS in NSData
I'm utterly perplexed by this problem because I thought that I'd been so
careful in ensuring that my data can be read safely with no problems.
This is my snippet of code:
[datastream getBytes:&bytes
range:NSMakeRange(positionCounter, datasize)]; // Length of packet content
positionCounter+= datasize;
datasize = (unsigned int)bytes; //This is the length of the
data indicated in the data structure from the capture.
if (positionCounter+datasize>[datastream length])
{
NSLog(@"Error - Bad size in datastream.");
datasize = [datastream length]-positionCounter-1; //the
minus one was just put there to ensure that we really are going to read a
little less data than we have available.
NSLog(@"length %lu, position %lu, datasize %lu,
pos+size %lu",[datastream
length],positionCounter,datasize,positionCounter+datasize); // the result of
this is length 18591, position 2974, datasize 15616, pos+size 18590
}
[datastream getBytes:&bytes
range:NSMakeRange(positionCounter, datasize)]; // Packet content
When this gets run, I get EXC_BAD_ACCESS code = 2 here. I'm demonstrably
reading less data than the file contains, and I've been able to read through
the file successfully up to this point. Please could someone suggest to me
what might be going wrong here?
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
EXC_BAD_ACCESS in NSData
I'm utterly perplexed by this problem because I thought that I'd been so
careful in ensuring that my data can be read safely with no problems.
This is my snippet of code:
[datastream getBytes:&bytes
range:NSMakeRange(positionCounter, datasize)]; // Length of packet content
positionCounter+= datasize;
datasize = (unsigned int)bytes; //This is the length of the
data indicated in the data structure from the capture.
if (positionCounter+datasize>[datastream length])
{
NSLog(@"Error - Bad size in datastream.");
datasize = [datastream length]-positionCounter-1; //the
minus one was just put there to ensure that we really are going to read a
little less data than we have available.
NSLog(@"length %lu, position %lu, datasize %lu,
pos+size %lu",[datastream
length],positionCounter,datasize,positionCounter+datasize); // the result of
this is length 18591, position 2974, datasize 15616, pos+size 18590
}
[datastream getBytes:&bytes
range:NSMakeRange(positionCounter, datasize)]; // Packet content
When this gets run, I get EXC_BAD_ACCESS code = 2 here. I'm demonstrably
reading less data than the file contains, and I've been able to read through
the file successfully up to this point. Please could someone suggest to me
what might be going wrong here?
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: EXC_BAD_ACCESS in NSData
On 26 May 2014, at 06:02, Pax <45rpmli...@googlemail.com> wrote: > This is my snippet of code: >[datastream getBytes:&bytes > range:NSMakeRange(positionCounter, datasize)]; // Length of packet content >positionCounter+= datasize; What is bytes declared as, and what do you initialize it to? Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.de ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: EXC_BAD_ACCESS in NSData
Apologies - the obvious important detail, and I missed it out entirely. I have tried both of the following with the same result: unsigned char* databuffer = (unsigned char*)malloc(datasize); [datastream getBytes:&databuffer range:NSMakeRange(positionCounter, datasize)]; // Packet content and unsigned char* bytes; [datastream getBytes:&bytes range:NSMakeRange(positionCounter, datasize)]; // Packet content Either way, I get the same result. On 26 May 2014, at 14:16, Uli Kusterer wrote: > On 26 May 2014, at 06:02, Pax <45rpmli...@googlemail.com> wrote: >> This is my snippet of code: >> [datastream getBytes:&bytes >> range:NSMakeRange(positionCounter, datasize)]; // Length of packet content >> positionCounter+= datasize; > > What is bytes declared as, and what do you initialize it to? > > Cheers, > -- Uli Kusterer > “The Witnesses of TeachText are everywhere...” > http://zathras.de > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: EXC_BAD_ACCESS in NSData
Apologies - the obvious important detail, and I missed it out entirely. I have tried both of the following with the same result: unsigned char* databuffer = (unsigned char*)malloc(datasize); [datastream getBytes:&databuffer range:NSMakeRange(positionCounter, datasize)]; // Packet content and unsigned char* bytes; [datastream getBytes:&bytes range:NSMakeRange(positionCounter, datasize)]; // Packet content Either way, I get the same result. On 26 May 2014, at 14:16, Uli Kusterer wrote: > On 26 May 2014, at 06:02, Pax <45rpmli...@googlemail.com> wrote: >> This is my snippet of code: >> [datastream getBytes:&bytes >> range:NSMakeRange(positionCounter, datasize)]; // Length of packet content >> positionCounter+= datasize; > > What is bytes declared as, and what do you initialize it to? > > Cheers, > -- Uli Kusterer > “The Witnesses of TeachText are everywhere...” > http://zathras.de > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSPopover + Bindings + Validation = Weirdness
On May 26, 2014, at 3:05 AM, Jonathan Mitchell wrote: > > On 26 May 2014, at 01:04, Keary Suska wrote: > >> I am implementing an editing view in a popover, and discovered that >> validations messages will cause exceptions because AppKit is broken in that >> regard...anyway so I set "always use application modal alerts" and that >> seems to work although the API is beeping somewhere after the alert is >> dismissed and I can't seem to find out why. This only happens when tabbing >> out of the field. I have a "commit" button that calls commitEditing and the >> validation message appears and there is no beep when it is dismissed. > Have you tried overriding : > > NSResponder - (void)presentError:(NSError *)error modalForWindow:(NSWindow > *)aWindow delegate:(id)delegate didPresentSelector:(SEL)didPresentSelector > contextInfo:(void *)contextInfo > > You can access the NSWindow instance at > popoverObject.contentViewController.view.window;. > > It might be possible to work around the AppKit bug. The bug is triggered when trying to display a sheet on a popover window, so even if I capture error presentation I would still have to present a modal alert of some kind. I was hoping the API would do that for me gracefully, but I was apparently wrong. I could give it a try and see if it behaves better. >> I suspect that the tab key event is somehow not being handled and is passed >> up the responder chain to something that doesn't like it so beeps. > This seems likely. > You could try just handling this event yourself within the responder chain. > > I find that using XSViewController improves the whole NSView + responder > chain experience. I do force insert my view controller into the responder chain, although really just to capture -cancelOperation calls so I can dismiss popovers with the ESC key. Perhaps this is the problem. I will look up that alley as well. Thanks, Keary Suska Esoteritech, Inc. "Demystifying technology for your home or business" ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSPopover + Bindings + Validation = Weirdness
On 26 May 2014, at 14:50, Keary Suska wrote: > > The bug is triggered when trying to display a sheet on a popover window, so > even if I capture error presentation I would still have to present a modal > alert of some kind. I was hoping the API would do that for me gracefully, but > I was apparently wrong. I could give it a try and see if it behaves better. Hmm. You could try using another popover to present the error. Your existing app modal presentation might be the best way of dealing with this. Jonathan ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: EXC_BAD_ACCESS in NSData
Well, I find your code to be a bit confusing, but I’d say that both of those are wrong. I think that what you need is: unsigned char* databuffer = (unsigned char*)malloc(datasize); [datastream getBytes:databuffer range:NSMakeRange(positionCounter, datasize)]; // Packet content On May 26, 2014, at 3:44 PM, Pax <45rpmli...@googlemail.com> wrote: > Apologies - the obvious important detail, and I missed it out entirely. I > have tried both of the following with the same result: > > unsigned char* databuffer = (unsigned char*)malloc(datasize); > [datastream getBytes:&databuffer range:NSMakeRange(positionCounter, > datasize)]; // Packet content > > and > > unsigned char* bytes; > [datastream getBytes:&bytes range:NSMakeRange(positionCounter, datasize)]; > // Packet content > > Either way, I get the same result. > > > > On 26 May 2014, at 14:16, Uli Kusterer wrote: > >> On 26 May 2014, at 06:02, Pax <45rpmli...@googlemail.com> wrote: >>> This is my snippet of code: >>> [datastream getBytes:&bytes >>> range:NSMakeRange(positionCounter, datasize)]; // Length of packet content >>> positionCounter+= datasize; >> >> What is bytes declared as, and what do you initialize it to? >> >> Cheers, >> -- Uli Kusterer >> “The Witnesses of TeachText are everywhere...” >> http://zathras.de >> > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/mcguffogl%40gmail.com > > This email sent to mcguff...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: EXC_BAD_ACCESS in NSData
Just to answer my own question, I find that: bytes=[[datastream subdataWithRange:NSMakeRange(positionCounter, datasize)]bytes]; Works perfectly. I should, I know, find out what was going wrong initially - but since I'd rather not have a copy anyway, this really is the all-round better solution. On 26 May 2014, at 15:25, Sandy McGuffog wrote: > Well, > > I find your code to be a bit confusing, but I’d say that both of those are > wrong. I think that what you need is: > > unsigned char* databuffer = (unsigned char*)malloc(datasize); > [datastream getBytes:databuffer range:NSMakeRange(positionCounter, > datasize)]; // Packet content > > > On May 26, 2014, at 3:44 PM, Pax <45rpmli...@googlemail.com> wrote: > >> Apologies - the obvious important detail, and I missed it out entirely. I >> have tried both of the following with the same result: >> >> unsigned char* databuffer = (unsigned char*)malloc(datasize); >> [datastream getBytes:&databuffer range:NSMakeRange(positionCounter, >> datasize)]; // Packet content >> >> and >> >> unsigned char* bytes; >> [datastream getBytes:&bytes range:NSMakeRange(positionCounter, datasize)]; >> // Packet content >> >> Either way, I get the same result. >> >> >> >> On 26 May 2014, at 14:16, Uli Kusterer wrote: >> >>> On 26 May 2014, at 06:02, Pax <45rpmli...@googlemail.com> wrote: This is my snippet of code: [datastream getBytes:&bytes range:NSMakeRange(positionCounter, datasize)]; // Length of packet content positionCounter+= datasize; >>> >>> What is bytes declared as, and what do you initialize it to? >>> >>> Cheers, >>> -- Uli Kusterer >>> “The Witnesses of TeachText are everywhere...” >>> http://zathras.de >>> >> >> ___ >> >> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) >> >> Please do not post admin requests or moderator comments to the list. >> Contact the moderators at cocoa-dev-admins(at)lists.apple.com >> >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/cocoa-dev/mcguffogl%40gmail.com >> >> This email sent to mcguff...@gmail.com > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: EXC_BAD_ACCESS in NSData
So you have unsigned char *bytes; and then datasize = (unsigned int)bytes; which sets datasize to the address of bytes cast to an unsigned integer which has nothing to do with the data in bytes at all and in some cases just truncates the address (OSX for instance) datasize = *((unsigned int*)bytes); is a bit closer to what you might want but is endian-unaware. On 26 May, 2014, at 9:44 pm, Pax <45rpmli...@googlemail.com> wrote: > Apologies - the obvious important detail, and I missed it out entirely. I > have tried both of the following with the same result: > > unsigned char* databuffer = (unsigned char*)malloc(datasize); > [datastream getBytes:&databuffer range:NSMakeRange(positionCounter, > datasize)]; // Packet content > > and > > unsigned char* bytes; > [datastream getBytes:&bytes range:NSMakeRange(positionCounter, datasize)]; > // Packet content > > Either way, I get the same result. > > > > On 26 May 2014, at 14:16, Uli Kusterer wrote: > >> On 26 May 2014, at 06:02, Pax <45rpmli...@googlemail.com> wrote: >>> This is my snippet of code: >>> [datastream getBytes:&bytes >>> range:NSMakeRange(positionCounter, datasize)]; // Length of packet content >>> positionCounter+= datasize; >> >> What is bytes declared as, and what do you initialize it to? >> >> Cheers, >> -- Uli Kusterer >> “The Witnesses of TeachText are everywhere...” >> http://zathras.de >> > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/rols%40rols.org > > This email sent to r...@rols.org ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
UICollectionViewCell and UIScrollView and autolayout
I've built a little demo project where I am struggling with autolayout. https://github.com/tcurdt/paging-and-zooming I basically have a fullscreen collection view to page through some scroll views that allow zooming into an image. When the UICollectionViewCells are being configured https://github.com/tcurdt/paging-and-zooming/blob/master/Paging/TCPagingView.m#L159 autolayout has assigned a frame to the cell. But somehow the UIScrollView is still at CGRectZero ...and somehow I cannot convince autolayout to assign the proper frame. Oddly enough it still show the image though - I just cannot center the scroll view. My head hurts. If someone with some more autolayout experience could share some wise word - that would be awesome. cheers, Torsten ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: EXC_BAD_ACCESS in NSData
On May 26, 2014, at 8:43 AM, Pax <45rpmli...@googlemail.com> wrote: > I should, I know, find out what was going wrong initially - but since I'd > rather not have a copy anyway, this really is the all-round better solution. What was wrong was that instead of passing the address of the buffer you allocated, you were passing the address of the variable which held the address of the buffer. But beyond that, the fact that you even tried: unsigned char* bytes; [datastream getBytes:&bytes range:NSMakeRange(positionCounter, datasize)]; // Packet content and weren't sure whether it would work, indicates that you have a big gap in understanding pointers & memory, and this needs to be fixed or you'll continue to create crashing bugs, some of which will not be nice enough to show up every time you run the code ;-) If you haven't already, studying a good tutorial on C or Objective-C is in order. If you have, then reviewing the sections on pointers and dynamic memory is in order. -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: EXC_BAD_ACCESS in NSData
The first one of those is ok - as long as you remember to free databuffer later. The second is wrong, the argument to getBytes:range: has to be an allocated buffer of size at least the length of the range you pass in. That second one is just copying data to a random place in memory, probably zero. On 26 May, 2014, at 9:44 pm, Pax <45rpmli...@googlemail.com> wrote: > Apologies - the obvious important detail, and I missed it out entirely. I > have tried both of the following with the same result: > > unsigned char* databuffer = (unsigned char*)malloc(datasize); > [datastream getBytes:&databuffer range:NSMakeRange(positionCounter, > datasize)]; // Packet content > > and > > unsigned char* bytes; > [datastream getBytes:&bytes range:NSMakeRange(positionCounter, datasize)]; > // Packet content > > Either way, I get the same result. > > > > On 26 May 2014, at 14:16, Uli Kusterer wrote: > >> On 26 May 2014, at 06:02, Pax <45rpmli...@googlemail.com> wrote: >>> This is my snippet of code: >>> [datastream getBytes:&bytes >>> range:NSMakeRange(positionCounter, datasize)]; // Length of packet content >>> positionCounter+= datasize; >> >> What is bytes declared as, and what do you initialize it to? >> >> Cheers, >> -- Uli Kusterer >> “The Witnesses of TeachText are everywhere...” >> http://zathras.de >> > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/rols%40rols.org > > This email sent to r...@rols.org ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: EXC_BAD_ACCESS in NSData
On May 26, 2014, at 9:05 AM, Roland King wrote: > The first one of those is ok... No, it's not--take a closer look ;-) > unsigned char* databuffer = (unsigned char*)malloc(datasize); > [datastream getBytes:&databuffer range:NSMakeRange(positionCounter, > datasize)]; -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: EXC_BAD_ACCESS in NSData
On 26 May 2014, at 06:44, Pax <45rpmli...@googlemail.com> wrote: > Apologies - the obvious important detail, and I missed it out entirely. I > have tried both of the following with the same result: > > unsigned char* databuffer = (unsigned char*)malloc(datasize); > [datastream getBytes:&databuffer range:NSMakeRange(positionCounter, > datasize)]; // Packet content As Scott says, you’re passing the address of a variable containing the address of the allocated memory, instead of just giving it the address of the allocated memory as you should. It’s like being asked to enter your address into a form, and instead you give them the address of a friend where they’re supposed to ask for your address. Since they don’t expect that, they will just deliver your order to your friend. No surprise it doesn’t work. > and > > unsigned char* bytes; > [datastream getBytes:&bytes range:NSMakeRange(positionCounter, datasize)]; > // Packet content > > Either way, I get the same result. This makes no sense. You’re still giving the address of a variable that can contain an address (which is wrong), but even if you didn’t: Since you never actually write an address into ‘bytes’ you get a random value (whatever happened to be in that location in memory at the time). You may want to read some more about memory, pointers etc. (like the parts I wrote in my ‘Masters of the Void’ C tutorial: http://masters-of-the-void.com/book5.htm) to make sure you have a correct understanding. Something still seems to be fuzzy in your head. Oh, and as Roland wrote, don’t forget to free() the pointer once you’re done with it. Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.de ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: EXC_BAD_ACCESS in NSData
Too true. That was a lot of bugs in 4 lines! > On 26 May, 2014, at 11:18 pm, Scott Ribe wrote: > >> On May 26, 2014, at 9:05 AM, Roland King wrote: >> >> The first one of those is ok... > > No, it's not--take a closer look ;-) > >> unsigned char* databuffer = (unsigned char*)malloc(datasize); >> [datastream getBytes:&databuffer range:NSMakeRange(positionCounter, >> datasize)]; > > > -- > Scott Ribe > scott_r...@elevated-dev.com > http://www.elevated-dev.com/ > (303) 722-0567 voice > > > > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: EXC_BAD_ACCESS in NSData
On May 26, 2014, at 9:32 AM, Uli Kusterer wrote: > Oh, and as Roland wrote, don’t forget to free() the pointer once you’re done > with it. But, just to be 100% clear, *not* the one you get from calling the bytes method ;-) -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: UICollectionViewCell and UIScrollView and autolayout
OK, so it seems I explicitly need to call [cell setNeedsLayout]; [cell layoutIfNeeded]; after the cell is configured. I didn't think the `layoutIfNeeded` was necessary. That's a bit of a surprise. The centering of the `UIScrollView` is still a bit funky though. Based on the `contentOffset` it works - except for the weird jumping on release. The `contentInset` approach does not work until you zoom. cheers, Torsten ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: UICollectionViewCell and UIScrollView and autolayout
Why is autolayout assigning a frame to the cell? Are you putting autolayout constraints on your cell? If so, shouldn’t be. The collection view assigns the cell’s frame (according to the wishes of the assigned collectionViewLayout). Setting the frame yourself, either by calling -setFrame or something that will affect frame on your behalf, such as using autolayout constraints, or autoresizing masks on the cell is unsupported. Luke On May 26, 2014, at 8:00 AM, Torsten Curdt mailto:tcu...@vafer.org>> wrote: autolayout has assigned a frame to the cell ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: EXC_BAD_ACCESS in NSData
Shameful. I need more sleep! :-) I also need to reread my code more carefully before asking questions. As I say though, I think that the solution I posted is the better solution anyway - since who wants a copy, with the additional overhead that a copy entails, when you don't need to have one? On 26 May 2014, at 16:33, Roland King wrote: > Too true. That was a lot of bugs in 4 lines! > >> On 26 May, 2014, at 11:18 pm, Scott Ribe wrote: >> >>> On May 26, 2014, at 9:05 AM, Roland King wrote: >>> >>> The first one of those is ok... >> >> No, it's not--take a closer look ;-) >> >>> unsigned char* databuffer = (unsigned char*)malloc(datasize); >>> [datastream getBytes:&databuffer range:NSMakeRange(positionCounter, >>> datasize)]; >> >> >> -- >> Scott Ribe >> scott_r...@elevated-dev.com >> http://www.elevated-dev.com/ >> (303) 722-0567 voice >> >> >> >> ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: UICollectionViewCell and UIScrollView and autolayout
I am not assigning a frame - but I am indeed assigning constraints to the subviews of the UICollectionViewCell's content view: https://github.com/tcurdt/paging-and-zooming/blob/master/Paging/TCPagingView.m#L17 That is not supported? cheers, Torsten On Mon, May 26, 2014 at 5:59 PM, Luke Hiesterman wrote: > Why is autolayout assigning a frame to the cell? Are you putting autolayout > constraints on your cell? If so, shouldn’t be. The collection view assigns > the cell’s frame (according to the wishes of the assigned > collectionViewLayout). Setting the frame yourself, either by calling > -setFrame or something that will affect frame on your behalf, such as using > autolayout constraints, or autoresizing masks on the cell is unsupported. > > Luke > > On May 26, 2014, at 8:00 AM, Torsten Curdt wrote: > > autolayout has assigned a frame to the cell > > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: UICollectionViewCell and UIScrollView and autolayout
That is fine, but the statement made in your original email said “autolayout has assigned a frame to the cell.” You’re free to use autolayout inside the content view - just don’t try to layout the cell itself. Luke On May 26, 2014, at 9:07 AM, Torsten Curdt mailto:tcu...@vafer.org>> wrote: I am not assigning a frame - but I am indeed assigning constraints to the subviews of the UICollectionViewCell's content view: https://github.com/tcurdt/paging-and-zooming/blob/master/Paging/TCPagingView.m#L17 That is not supported? cheers, Torsten On Mon, May 26, 2014 at 5:59 PM, Luke Hiesterman wrote: Why is autolayout assigning a frame to the cell? Are you putting autolayout constraints on your cell? If so, shouldn’t be. The collection view assigns the cell’s frame (according to the wishes of the assigned collectionViewLayout). Setting the frame yourself, either by calling -setFrame or something that will affect frame on your behalf, such as using autolayout constraints, or autoresizing masks on the cell is unsupported. Luke On May 26, 2014, at 8:00 AM, Torsten Curdt wrote: autolayout has assigned a frame to the cell ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: EXC_BAD_ACCESS in NSData
On May 26, 2014, at 10:06 AM, Pax <45rpmli...@googlemail.com> wrote: > As I say though, I think that the solution I posted is the better solution > anyway - since who wants a copy, with the additional overhead that a copy > entails, when you don't need to have one? Absolutely. (For read-only access.) -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: UICollectionViewCell and UIScrollView and autolayout
Ah - so that was the `UICollectionViewFlowLayout` that did that (if understand you correctly)? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: UICollectionViewCell and UIScrollView and autolayout
> On May 26, 2014, at 12:10 PM, Luke Hiesterman wrote: > > That is fine, but the statement made in your original email said “autolayout > has assigned a frame to the cell.” You’re free to use autolayout inside the > content view - just don’t try to layout the cell itself. In practice, this restriction is extremely difficult to obey, because constraints are not directional. If you want a subview to be _affected by_ the collection view cell’s frame, it must necessarily also have the potential to affect the collection view cell’s frame. You can’t just prohibit lines drawn from subviews to the superview; instead you have to ensure those are dominated at all times by the autoresizing-mask constraints installed by the collection view layout. The most difficult time to uphold this restriction is usually during view setup when you’re installing constraints manually but the autoresizing mask constraints haven’t yet been generated. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Mutating NSLayoutConstraint -constant at run time
So: 1. I have a NSView V within a view hierarchy. 2. V holds a layout constraint C that offsets a subview S from the bottom edge of V. 3. At runtime I mutate -constant on constraint C. The question is should the view hierarchy automatically recalculate its layout in response to changing the constant on C? In practice I find that I have to call -layoutSubtreeIfNeeded on a superview of V. I do not have to call -setNeedsLayout:YES Note: My actual implementation is more complex than the above. V exists with an NSStackView subclass, so there are a lot of constraints at play. However, if I can clarify the above it will help my thinking. Jonathan ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: EXC_BAD_ACCESS in NSData
On May 26, 2014, at 6:02 AM, Pax <45rpmli...@googlemail.com> wrote: > When this gets run, I get EXC_BAD_ACCESS code = 2 here. I'm demonstrably > reading less data than the file contains, and I've been able to read through > the file successfully up to this point. Please could someone suggest to me > what might be going wrong here? Use the debugger to look at the values of the relevant variables, especially dataSize. Since the result is a crash instead of an exception, the NSRange you create is valid; so I assume it’s just larger than your buffer so the copy runs off the end into unmapped address space. Also, what exactly is the type of ‘bytes’? If it’s a pointer to a malloced buffer, you shouldn’t be passing its address, rather its value, otherwise you’re going to copy into the stack and blow up. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: EXC_BAD_ACCESS in NSData
On 27 May 2014, at 12:54 am, Roland King wrote: > datasize = *((unsigned int*)bytes); > > is a bit closer to what you might want but is endian-unaware. That's just as wrong - you are using the first few bytes of the data as the length, which it certainly isn't (except for possibly a very few special cases that just so happen to have the length as the first field of the data). --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: EXC_BAD_ACCESS in NSData
On May 26, 2014, at 4:20 PM, Graham Cox wrote: > That's just as wrong - you are using the first few bytes of the data as the > length, which it certainly isn't (except for possibly a very few special > cases that just so happen to have the length as the first field of the data). No, it’s extremely common to have a data format where a variable-length field is prefixed with its length. That looks like what this code is trying to read. The right way to do this would be something like: uint32_t length = *(uint32_t*)bytes; length = CFSwapInt32BigToHost(length); You need to be explicit about the size of integer in use (“int” has different sizes on different platforms) and you need to convert from the byte-order used in the file format (which is almost always big-endian.) —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: EXC_BAD_ACCESS in NSData
On 26 May 2014, at 16:20, Graham Cox wrote: > On 27 May 2014, at 12:54 am, Roland King wrote: >> datasize = *((unsigned int*)bytes); >> >> is a bit closer to what you might want but is endian-unaware. > > That's just as wrong - you are using the first few bytes of the data as the > length, which it certainly isn't (except for possibly a very few special > cases that just so happen to have the length as the first field of the data). It’s not a general truth, true, but from what the OP mentioned, he’s sequentially reading stuff from his big NSData: >datasize = (unsigned int)bytes; //This is the length of > the data indicated in the data structure from the capture. So there you need to correctly cast the start of the data into a pointer to the right size of int (in general, you’d use some stable type like uint32_t instead of unsigned int for portability, though), and then de-reference it to read. Regarding endian-swapping, that depends on the file format. If you wrote that file yourself, you don’t usually need to do any swapping. Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.de ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: EXC_BAD_ACCESS in NSData
On 27 May 2014, at 10:13 am, Jens Alfke wrote: > No, it’s extremely common to have a data format where a variable-length field > is prefixed with its length. That looks like what this code is trying to read. Alright, but you have to know that. I was looking at the code from a general standpoint, where its format was unknown - just a blob of data. Also, just reading the bytes blindly doesn't take into account endianness, though you and Roland do mention that. What I prefer to do when parsing blobs of data like this is declare types that represent chunks of the format, such as a struct that matches the header (being careful about matching the padding used by the file) then cast or copy the data buffer, taking into account endianness, into that type. It makes the code a lot more readable, because you are not just reading from a arbitrary offset, but are using a named field. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: EXC_BAD_ACCESS in NSData
On May 26, 2014, at 7:43 PM, Uli Kusterer wrote: > Regarding endian-swapping, that depends on the file format. If you wrote that > file yourself, you don’t usually need to do any swapping. That's true. For example, back in the PowerPC days, we never had to endian-swap our file formats, because we knew that our file format was created on a Mac, and Macs always used big-endian, and it wasn't as if Apple was ever going to do anything crazy like switch to Intel or anything. Nowadays, of course, we can be assured that our code will always run on Intel processors, because *obviously* there's no reason your code would ever need to run on something like ARM. Hmm. Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
