Hi Stephen,
Thanks for your help.
No, the tool is not an App/Bundle, it is native command line Tool
which embeds the File version Plist in itself. I am trying to find a
generic way to read version information from such binaries (32/64 bit)
if they have file version plist embeded with them.
Thank
Do you mean the app/bundle version? CFBundleGetValueForInfoDictionaryKey()
with kCFBundleVersionKey.
On Tue, Nov 27, 2012 at 12:41 AM, Sachin Porwal wrote:
> Hi,
>
> I am looking for a way to read file version information of a native
> Binary(32/64 bit) in Cocoa. This is required to upgrade a ex
Hi,
I am looking for a way to read file version information of a native
Binary(32/64 bit) in Cocoa. This is required to upgrade a existing
tool on target system from my custom installer.
Could you please point me in right direction? Much appreciated
Thanks,
Sachin
On Nov 26, 2012, at 6:07 PM, Ken Ferry wrote:
> Think of setFrame: outside of layout the same way you think of drawing
> outside of drawRect:
>
> It will "work" in the sense that the frame will be changed, but it's just
> going to get stomped the next time the layout pass comes around.
Ac
On Nov 26, 2012, at 6:04 PM, Matt Neuburg wrote:
> PS Is there any merit to my suggestion that the runtime should warn if you
> set the frame of a constrained interface object? I really think such a
> warning would save a lot of programmers from shooting themselves in the foot.
> It is so easy
Think of setFrame: outside of layout the same way you think of drawing outside
of drawRect:
It will "work" in the sense that the frame will be changed, but it's just going
to get stomped the next time the layout pass comes around.
Sent from my iPhone
On Nov 26, 2012, at 10:46 AM, Matt Neub
Perfect, just what I needed. m.
PS Is there any merit to my suggestion that the runtime should warn if you set
the frame of a constrained interface object? I really think such a warning
would save a lot of programmers from shooting themselves in the foot. It is so
easy to switch to auto layout
On 27 Nov, 2012, at 7:25 AM, Kyle Sluder wrote:
> On Mon, Nov 26, 2012, at 12:57 PM, Matt Neuburg wrote:
>> It would help me if you could suggest a method call that would exercise
>> the constraint system, e.g. perhaps causing the frame to snap back to
>> height 36, thus proving to the student t
On Mon, Nov 26, 2012, at 12:57 PM, Matt Neuburg wrote:
> It would help me if you could suggest a method call that would exercise
> the constraint system, e.g. perhaps causing the frame to snap back to
> height 36, thus proving to the student that this behavior is problematic.
> I tried things like
My view does not translate its autoresizing mask. But you are confirming my
suspicion that some issue is lurking here. I wonder if it wouldn't be better if
some kind of runtime warning were issued when I do this sort of thing...
It would help me if you could suggest a method call that would exe
On Mon, Nov 26, 2012, at 10:46 AM, Matt Neuburg wrote:
> I have noticed by experimentation that if I have a layout constraint on a
> view that sets its height at (say) 36, I can later change the view's
> frame in code to set its height at (say) 50. The view's height does
> visibly change, but loggi
I have noticed by experimentation that if I have a layout constraint on a view
that sets its height at (say) 36, I can later change the view's frame in code
to set its height at (say) 50. The view's height does visibly change, but
logging proves that the layout constraint does not change.
(1) H
On 21 Nov 2012, at 10:56, Andreas Grosam wrote:
> I've defined a class Foo that defines a block via a property:
>
> @property (copy) void (^progressHandler)(RXProgressState progressState,
> NSInteger totalBytesWritten, NSInteger totalBytesExpectedToWrite);
>
> The property is synthesized by the
13 matches
Mail list logo
