Professional Web Applications Themes

Becoming a Macintosh Programming Guru [C++ & how?] - Mac Programming

In article <bp10qm$1jhcui$news.uni-berlin.de>, Thomas Engelmeier <com> wrote:   > > So Cocoa exception macros mix with C++ exceptions by now?[/ref] I doubt it. The new part-of-the-language exception constructs (try, throw, etc.) are supposed to be binary-compatible with the old exception macros, so I'm sure they have the same limitations. I don't see why you would take my statement as to imply ObjC/C++ exception compatibility, though. C's setjmp()/longjmp() aren't very compatible with C++ objects either, but people still manage. Of course you have to be careful with exceptions; if a C++ exception can be thrown through Cocoa code, then you have ...

  1. #41

    Default Re: Becoming a Macintosh Programming Guru [C++ & how?]

    In article <bp10qm$1jhcui$news.uni-berlin.de>,
    Thomas Engelmeier <com> wrote:
     
    >
    > So Cocoa exception macros mix with C++ exceptions by now?[/ref]

    I doubt it. The new part-of-the-language exception constructs (try,
    throw, etc.) are supposed to be binary-compatible with the old
    exception macros, so I'm sure they have the same limitations.

    I don't see why you would take my statement as to imply ObjC/C++
    exception compatibility, though. C's setjmp()/longjmp() aren't very
    compatible with C++ objects either, but people still manage. Of course
    you have to be careful with exceptions; if a C++ exception can be thrown
    through Cocoa code, then you have to make sure everything is properly
    autoreleased. If an ObjC exception can be thrown through C++ code, then
    you have to make sure nothing bad will happen as a result of stack-based
    objects' destructors not being called.

    I didn't say it was some perfect nirvana. What it *is*, is a way to mix
    ObjC and C++. I personally find Safari to be an excellent product, so
    obviously it is possible to produce something that works very well using
    ObjC++.
     
    >
    > So who is writing good - and SOLID - Cocoa code? Quite a bunch of the
    > Cocoa Applications I see crashing due undefined behavior with some
    > unhandled Objc message or unhandled nil objects, something current C++
    > coding practice (exceptions, smart objects, strong type checking) should
    > avoid.[/ref]

    With the exception of the Finder and this newsreader, every application
    I use on anything resembling a regular basis is a Cocoa app, both Apple
    and third-party stuff. So my impression is that a lot of people are
    writing good and solid Cocoa code. Of course bad or inexperienced
    programmers will write Cocoa code that throws a lot of exceptions (note
    that unhandled messages always generate exceptions, not crashes, and nil
    objects either generate exceptions or are simply a no-op in the case of
    messaging to nil), just like bad or inexperienced programmers will write
    C++ code that segfaults a lot.
     

    Error checking is only really necessary when interacting with something
    that can produce an error in the normal course of operation. By this, I
    mean things like reading from a file, opening a socket, etc. Sending a
    message to an object of unknown type doesn't need error-checking; either
    you catch the exception that it will throw, or you test your code to be
    sure that the wrong type of object is never passed in. The facts that a
    lot of errors are signalled by returning nil, and messages to nil have
    no effect, can be used to cleanly delay error checking until the end of
    a sequence of messages.

    One 'problem' is that Cocoa makes it very easy for someone who is
    inexperienced to write an app that looks good, but functions badly.
    Whereas a beginning C++ programmer may be struggling to put a window on
    the screen, a beginning Cocoa programmer has a nice-looking GUI wrapped
    around code that is probably doing all kinds of weird, horrible stuff.
    As a result, a fair number of these bad-on-the-inside programs actually
    get released to the world. You shouldn't take them as being
    representative any more than the equivalent
    ugly-and-segfaulting-all-the-time C++ program.
    Michael Guest

  2. #42

    Default Re: Becoming a Macintosh Programming Guru [C++ & how?]

    dans l'article mail-9171E3.12454314112003localhost, Michael Ash à
    com a écrit le 14/11/03 12:45:
     

    By the way, CW allows this since 8.3. I'm using it every day.

    Eric

    Eric Guest

  3. #43

    Default Re: Becoming a Macintosh Programming Guru [C++ & how?]

    Michael Ash <com> wrote in message news:<mail-1C8989.21572113112003localhost>... 

    I'm not for a moment suggesting these things can't be done in ObjC or
    Cocoa. Merely that by reusing a simple, common metaphor (such as
    operator + for string concatenation), a programmer new to ObjC/Cocoa
    trys it, remembers and moves on. IMO, the less reliance on
    framework-specific methods of simple manipulating of basic data types
    (in this case, strings) the better.

    Ease of use isn't just something for newbie users, even for seasoned
    programmers it's useful to reuse common concepts so they don't have to
    learn from scratch. (FYI, I knew a developer who used to force his
    (newbie) users to use old green screen Wang terminals for word
    processing and the like, because he didn't/couldn't learn how to
    program for Windows or Macs).
     

    Isn't that method only in NSKeyedArchiver? I was using non-keyed
    archiving. In any case, I found another way around the problem.

    [snip for brevity] 

    Thanks for the info, seems I was wrong to draw a parallel between the
    two. The concept of mix-in classes is the most useful aspect of
    multiple inheritance to me, and seems to me to be a very OO, (i.e.
    code reuse with minimal work involved).
     

    Which is probably the best way to learn! I'll put my hand up here and
    say I've never had a OSX only contract, so I've never 'had' to use
    ObjC. I am using it now for my pet project, though without the
    pressure of someone looking over my shoulder! ;)
     

    Yup, that's what I now do too.

    But this is the benefit of more integrated toolset, there's no need to
    manually create the actions and controls, nor connect them.
     
    :)
     
    >
    > Likewise. It's always nice to hear from the other side. And of course,
    > if I can make another convert, that's great too. :)[/ref]

    How many do you have to convert before you get the free T-shirt? No,
    I'm already convinced, I just feel a little frustrated it's taken
    (taking?) longer than I expected to get up to speed. I'd like to think
    it has more to do with the reasons I've mentioned, rather than being a
    stoopid programmer!

    Cheers!
    Mike.
    Mike Guest

  4. #44

    Default Re: Becoming a Macintosh Programming Guru [C++ & how?]

    Doc O'Leary <com> wrote in message news:<supernews.com>... 
    >
    > Perhaps you simply haven't "seen" enough. Don't fault a language when
    > you simply don't have a firm language base to approach it on. How long
    > have you done Smalltalk or Lisp development? Tried any other
    > non-bandwagon OO languages like Self or Io? Really, anyone who is
    > confused by the trivial additions that ObjC makes to C shouldn't even
    > *think* of touching C++.[/ref]

    No, I haven't used Smalltalk or Lisp. (I'd never even heard of Self or
    Io, are these in common usage?) I've developed with C, C++, (now ObjC
    too), Pascal (incl Delphi Pascal), Object Pascal, Fortran, in addition
    to high level stuff like PowerScript; and assembly on various
    platforms. That's a reasonable language base consisting of high level,
    low level, OO and non-OO languages to compare to. (I'm not sure what
    you mean by 'bandwagon'. )
     
    >
    > As Mr. Ash points out, operator overloading as commonly practiced in C++
    > is poorly thought out. To add is not to append, and so overloading the
    > + operator to make the two look the same is a dumb thing to do.[/ref]

    On a logical level, you're right of course. '+' doesn't do any kind of
    bizzard character munging. On a pragmatic level, you're dead wrong.
    Even newbie OO programmers are comfortable with the concept of such
    operators, it's a good idea to leverage that familiarity.
     

    I don't see why that's a good thing.
     

    I really don't follow your logic here. MI is wrong because it's useful
    and flexible?
     

    Snap.

    Just because other developers find some aspects of ObjC
    counter-intuitive doesn't make them stupid either. Personally, I
    picked up, and have been using C++ for some time without problems. The
    only drawback I've experienced is the lack of decent RAD tools on the
    Mac.
     

    No, posting to a newsgroup for help is never my first recourse, I find
    it better to try and work through the problem first. (But thanks for
    the amateur psychology).
     

    No, it's just one example of an anachronism in a Cocoa development
    tool, which forced me to waste my precious time trying to figure out
    how to perform the simplest of actions. Had it been a button and Open
    panel, it would have taken 10 seconds. Instead, it took me several
    minutes looking through sample projects. When is inconvenience ever a
    good thing?
     

    This again points to your apparent willingness to resort to amateur
    psychology rather than admit to ANY deficincies in ObjC, Cocoa, or the
    toolset.
     

    I didn't, because the image icon wasn't something I wanted to hard
    code.
    (And less of the insults, eh?)

    Mike.
    Mike Guest

  5. Moderated Post

    Default Re: Becoming a Macintosh Programming Guru [C++ & how?]

    Removed by Administrator
    Doc Guest
    Moderated Post

  6. #46

    Default Re: Becoming a Macintosh Programming Guru [C++ & how?]

    In article <google.com>,
    utvinternet.com (Mike Whooley) wrote:
     
    >
    > I'm not for a moment suggesting these things can't be done in ObjC or
    > Cocoa. Merely that by reusing a simple, common metaphor (such as
    > operator + for string concatenation), a programmer new to ObjC/Cocoa
    > trys it, remembers and moves on. IMO, the less reliance on
    > framework-specific methods of simple manipulating of basic data types
    > (in this case, strings) the better.
    >[/ref]

    In theory, this is reasonable, but in practice, the basic data types -
    in specific strings, fail for OS X development because they don't
    cleanly support Unicode (which is important for OS X programs). So you
    are then left with either CFStrings (via Carbon and "plain" C/C++) or
    NSString (via Cocoa and Objective-C).

    I've used both, and NSStrings are far easier to use, if for no other
    reason than auto-release pools, but also because CFString API seems
    "have as many parameters as possible in a routine to handle every
    possible case even though 99% of the times you don't need them" (how
    many people have actually used a CFAllocator other than the default one?)
    Glenn Guest

  7. #47

    Default Re: Becoming a Macintosh Programming Guru [C++ & how?]

    dans l'article google.com, Mike Whooley
    à utvinternet.com a écrit le 14/11/03 17:33:
     

    So it seems I'm not the only one to think that some people on this list
    simply won't accept facts.

    Eric

    Eric Guest

  8. #48

    Default Re: Becoming a Macintosh Programming Guru [C++ & how?]

    In article <BBDAD2E1.15762%fr>,
    Eric VERGNAUD <fr> wrote:
     
    >
    > So it seems I'm not the only one to think that some people on this list
    > simply won't accept facts.[/ref]

    Perhaps, but you seem to be the only one who thinks *everyone* simply
    won't accept facts. :P
    Michael Guest

  9. #49

    Default Re: Becoming a Macintosh Programming Guru [C++ & how?]

    In article <google.com>,
    utvinternet.com (Mike Whooley) wrote:
     

    Well, in C, ObjC, and even C++, strings aren't really basic data types.
    In ObjC, everything that isn't a primitive has different semantics,
    whereas in C++, non-primitives can use the same semantics as primitives.
    This can be good or bad; the problem is when it breaks down.
    Concatenating constant strings is one example of where the
    objects-act-like-primitives thing breaks down in C++, and there are
    others. That's what Doc meant (I think) when he says ObjC draws a clear
    line between C and ObjC. ObjC objects aren't primitives and operations
    on them have very different semantics and runtime costs; the operations
    reflect that.

    You could probably use Objective-C++ to write some automatic coercions
    that would transform id to a C++ string and back when you needed it. I
    would be very hesistant at how well such an approach would handle
    non-english languages, though. :)
     

    I agree completely, but I don't see this as an ease-of-use thing, just a
    less-typing thing. For strings, the number of operations you get 'for
    free' with operator overloading is so small as to be insignificant.
    (Really just concatenation and comparison; stuff like assignment
    overloading doesn't apply for a language that doesn't have
    stack-allocated objects anyway.)

    Now, I'm not totally against operator overloading by any means. For
    mathematical data types, I think they're great. It's very nice to be
    able to make a vector data type or a complex number type, or some other
    sort of numerical type where you can just write out your operations in
    normal mathematical notation in the program. But for non-numerical
    types, at least in C++, I think operator overloading does more harm than
    good. Strings aren't mathematical types, so the convenience gained by
    being able to 'add' them is very small. And I won't even get started on
    the amount of silliness that arises from overloading << and >> for IO
    operations.
     
    >
    > Isn't that method only in NSKeyedArchiver? I was using non-keyed
    > archiving. In any case, I found another way around the problem.[/ref]

    Sorry, I made a mistake about the method name. You're right that
    encodeInt: and friends is only in NSKeyedArchiver. Strangely, NSArchiver
    has a different method for every kind of primitive object,
    encodeValueOfObjCType:at:. You use it like this: [coder
    encodeValueOfObjCType:encode(float) at:&myFloat]. It works for any
    primitive type. I have to chalk this up to 'failure to properly read the
    doentation.' :)
     

    I have no experience with this, so could you give me an example or two
    of how this actually ends up working in practice? I think I get the
    idea, but I'd like to know how it works for real.
     
    >
    > Which is probably the best way to learn! I'll put my hand up here and
    > say I've never had a OSX only contract, so I've never 'had' to use
    > ObjC. I am using it now for my pet project, though without the
    > pressure of someone looking over my shoulder! ;)[/ref]

    I haven't had an OS X only contract either. When you see me talking
    about how ObjC is cross-platform, I'm not just blathering; I worked on
    an ObjC project running on Linux and Windows for about a year and a
    half. I only started with Cocoa later on. And let me tell you, compared
    to Swarm (the ObjC framework I was using on that project), Cocoa is a
    paradise of understandability, good design, and excellent doentation.
     

    You basically pull up the "onClick" action in the interface creator
    thingy and type your code in, right? That would be nice, but Apple is so
    tied to ObjC and gcc, which in turn are very heavily tied to the old C
    way of files-and-modules-and-makefiles development that I doubt this
    will happen.
     

    I don't know. I trust that I will be contacted once I have enough. Or
    perhaps it will simply arrive in the mail one fine morning....
     

    Well, as I said, some people just don't seem to get it quickly, while
    many of us do. Unlike others, I don't think it's because they're stupid.
    But I am at a total loss to explain why.

    [and now some replies to stuff from your message to Doc...] 

    The thing is, many people consider C++ to be an OO language, and it can
    even be true depending on what you call OO, but it's not the same kind
    of OO as SmallTalk, Self, or Objective-C. So unless Object Pascal or
    your 'high level stuff' had a very non-C++ OO system, then I would say
    your language base does not consist of OO languages to compare to. A lot
    of people who do a lot of C++ tend to think that C++ OO is simply OO,
    when in fact there are several different approaches to OO that produce
    very different capabilities and results. Some people, (sometimes myself
    included) go so far as to say that C++ is not 'real' OO because its
    approach is too limited.

    Given that, I'm not too surprised that you've had some trouble with
    ObjC. I'm not sure why it was easy for me, when I had a fairly similar
    background when I picked it up (dabbling with lisp and prolog and so on
    came later), but people who only have experience with C++-style OO do
    often have trouble properly grasping ObjC-style OO.
    Michael Guest

  10. #50

    Default Re: Becoming a Macintosh Programming Guru [C++ & how?]

    dans l'article mail-9E71C2.21254414112003localhost, Michael Ash à
    com a écrit le 14/11/03 21:25:
     
    >
    > Perhaps, but you seem to be the only one who thinks *everyone* simply
    > won't accept facts. :P[/ref]

    Mike, you're not being very fair. I wrote 'some'.

    Eric

    Eric Guest

  11. #51

    Default Re: Becoming a Macintosh Programming Guru [C++ & how?]

    In article <BBDB0443.15792%fr>,
    Eric VERGNAUD <fr> wrote:
     
    > >
    > > Perhaps, but you seem to be the only one who thinks *everyone* simply
    > > won't accept facts. :P[/ref]
    >
    > Mike, you're not being very fair. I wrote 'some'.[/ref]

    Well, you thought everybody who actually replied to you in That One
    Thread wouldn't accept facts.
    Michael Guest

  12. #52

    Default Re: Becoming a Macintosh Programming Guru [C++ & how?]

    dans l'article mail-B2DEA2.23035314112003localhost, Michael Ash à
    com a écrit le 14/11/03 23:03:
     

    And that's not everybody on this list.

    Eric

    Eric Guest

  13. #53

    Default Re: Becoming a Macintosh Programming Guru [C++ & how?]

    In article <supernews.com>,
    Doc O'Leary <com> wrote:
     
    >
    >Cocoa has a Java API as well. Unfortunately.[/ref]

    And this is the secret if you want to write portable code:
    just use Java.


    Simon Guest

  14. #54

    Default Re: Becoming a Macintosh Programming Guru [C++ & how?]

    Michael Ash <com> wrote:
     
    > >
    > > So Cocoa exception macros mix with C++ exceptions by now?[/ref]
    >
    > I doubt it. The new part-of-the-language exception constructs (try,
    > throw, etc.) are supposed to be binary-compatible with the old
    > exception macros, so I'm sure they have the same limitations.
    >
    > I don't see why you would take my statement as to imply ObjC/C++
    > exception compatibility, though. C's setjmp()/longjmp() aren't very
    > compatible with C++ objects either, but people still manage. Of course
    > you have to be careful with exceptions; if a C++ exception can be thrown
    > through Cocoa code, then you have to make sure everything is properly
    > autoreleased. If an ObjC exception can be thrown through C++ code, then
    > you have to make sure nothing bad will happen as a result of stack-based
    > objects' destructors not being called.[/ref]

    Setjmp is deprecated and pretty rarely used.

    Exceptions in both environments are suggested.

    IMO, to produce nonleaking hybrid ObjC++ code with correct exception
    behavior, you need theoretically wrap all potentially throwing ObjC
    message blocks in an try .. area, and the C++ blocks in try..
    catch(...) blocks in order to have cleanup and dtors called. Or to find
    other paradigmns, patch GCC etc,..
    Guessing "This is unlikely to happen" doesn't make the code behavior
    well-defined.
     

    It is, ditto with LaunchBar.
     

    My personal experience is different - YMMV.
    Mail.app crashes even at basic configuration attempts, as Keychain
    Access does when moving / copying entries. Project Builder has the
    largest CrashReporter.log on my machine even though I just tried to
    create somem samples and a simple toy application. And its "error
    handling" was definitely undefined, bad behavior.
     

    Do they? I was under the impression - using CarbonLib wraped ObjC
    objects - that [nil release]; aka CFRelease( null ); brought up a neat
    crash..

    Regards,
    Tom_E

    --
    This address is valid in its unmodified form but expires soon.

    Thomas Guest

  15. #55

    Default >

    Michael Ash <com> wrote:
     

    I wouldn't consider the design of std::string as the greatest C++
    design. It has been pretty often critzised and is a "working compromise".
     

    This is the intended usage.
     

    This is something also a significant number of C++ fans agree.
     
    >
    > Well, as I said, some people just don't seem to get it quickly, while
    > many of us do. Unlike others, I don't think it's because they're stupid.
    > But I am at a total loss to explain why.[/ref]

    It's not the OO style (I do use C++, Java and ObjC).

    It is about preferences, language features and needs.

    When I need to handle binary data I have a strong preference to use
    things like
    std::vector<int> and std::vector<CIntAndMore> and then an
    std::for_each() - Wrapping e.g. plain data into IntWrappers classes in
    order to put them in an ObjC or Java container is something I do not
    like at all.

    When I need to handle complex XML and XSL, I have some preference to use
    Java: There _automatic_ reference-counting and Unicode-normalized string
    handling and a whole bunch of libraries brings a lot of benefits.

    etc..

    reagrds,
    Tom_E

    --
    This address is valid in its unmodified form but expires soon.

    Thomas Guest

  16. #56

    Default Re: Becoming a Macintosh Programming Guru [C++ & how?]

    In article <bp5e50$1jgcs0$news.uni-berlin.de>,
    Thomas Engelmeier <com> wrote:
     

    Except that ObjC exceptions, at least the old macro-based variety, use
    setjmp() internally. I don't think the new-style ones use setjmp(), but
    since they're binary compatible I'm sure they have the same basic
    limitations.
     

    This is certainly true, unless you have no stack-allocated C++ objects
    sitting around.
     

    You can safely throw C++ exceptions through ObjC code as long as all
    existing objects have a total modification to their retain counts of
    zero in that block when the potential-exception-throwing code is called.
    There really is no difference between C++ and ObjC exceptions in this
    case. As far as ObjC code is concerned, both of them jump through to
    wherever they are caught without doing anything on the way. So the
    alternative to wrapping every call into C++ land in try/catch blocks is
    to simply make sure every newly-created object is autoreleased
    beforehand. Most code does this anyway.

    (One exception to the above; I'm sure that throwing a C++ exception
    won't trigger any ObjC finally blocks.)
     

    But you don't have to guess. Of course it takes some effort, and you
    have to pay attention to what you're doing, but you don't have to hope
    or rely on undefined behavior.

    [reliability of Cocoa apps] 

    I have never seen or heard of this happening. Either you're doing
    something very unusual, or your setup is broken somehow, I think. I have
    had Mail just freeze up every now and then, but not often.
     

    I just tried this and it seems to work ok. I'm using 10.3.1, I never
    really used Keychain Access before.
     

    PB/Xcode are very buggy programs, to be sure. But I wouldn't blame their
    bugginess on ObjC or Cocoa any more than I would blame Windows's
    bugginess on C.
     
    >
    > Do they? I was under the impression - using CarbonLib wraped ObjC
    > objects - that [nil release]; aka CFRelease( null ); brought up a neat
    > crash..[/ref]

    No, remember, the -release message isn't special in any way. It calls
    the ObjC messenger just like any other message. So [nil release] gets
    translated into objc_msgSend(nil, selector(release)). objc_msgSend()
    return 0 for messages sent to nil, it doesn't even look at the selector.

    There are some obscure pitfalls to this. Because objc_msgSend() has no
    information about the return value of the method, certain method types
    (I think it's anything that doesn't map to an int or pointer, such as a
    float, a 64-bit data type, or a struct) will return garbage. But for
    anything that returns an object, you are guaranteed to get nil as a
    result of sending a message to nil.
    Michael Guest

  17. #57

    Default Re: Becoming a Macintosh Programming Guru [C++ & how?]

    Thank you for your thoughts...I would like to finish up by saying:

    1) I would love to make our system competely modern. Remove the cruft
    or even dead code or dead resources. That is something that I am very
    vocal about.

    2) I am not in a position to steer the project in a direction. I have
    always appreciated the philosphy written in many programming books
    that if systems are in a bad state, you rewrite the systems piece by
    piece.

    3) I do not believe that I personally would be making the best
    investment of my time in switching over to Cocoa. If I had to make a
    change, it would be to continue developing in a programming language
    that many people use. Java, Python, etc... Something that is not
    Macintosh only. I love the Mac, but I've avoided being pigeonholed
    into a proprietary language up to this point and hope to continue this
    way. In the worst case scenario that I must switch to a proprietary
    language, it would be C# and .NET. Horrible as that sounds, my
    perspective has switched after getting married and having to take care
    of a family. Its all programming after all (ug, I don't like Windows
    look & feel).

    Anyway, my original post has produced a lot of discussion. I feel
    famous :)

    Lyndsey Ferguson
    Lyndsey Guest

  18. #58

    Default Re: Becoming a Macintosh Programming Guru [C++ & how?]

    dans l'article google.com, Lyndsey
    Ferguson à com a écrit le 15/11/03 17:43:
     

    It's warming to see that some people relate development to economics rather
    than religion.

    Good luck,

    Eric

    Eric Guest

  19. #59

    Default Re: Becoming a Macintosh Programming Guru [C++ & how?]

    In article <google.com>,
    com (Lyndsey Ferguson) wrote:
     

    You mixing things up. It's Cocoa that's Mac-only, not Objective-C:
    library vs. language. The Objective-C language is neither proprietary
    nor Mac-only. (You should also be aware that you're not tied to ObjC to
    write Cocoa apps, quite a few languages have been bridged to ObjC:
    Python, Ruby, Perl, Java, perhaps even more. I use PyObjC and am having
    a ball.)

    Just
    Just Guest

  20. #60

    Default Re: Becoming a Macintosh Programming Guru [C++ & how?]

    In article <supernews.com>,
    Doc O'Leary <com> wrote:
     

    It's actually worse than that: they use developers who have only
    ever worked on one platform. They have no experience of anything
    except one style of programming, one set of APIs, and one line of
    CPUs (and therefore one machine code as a basis for everything).

    They will have terrible trouble in porting to the Mac because they
    have no idea of all the things that can differ between Wintel and
    any other platform.


    Simon Guest

Page 3 of 6 FirstFirst 12345 ... LastLast

Similar Threads

  1. Macintosh - Font issues when viewed on macintosh
    By Steven in forum Web Design
    Replies: 1
    Last Post: July 1st, 01:45 PM
  2. Replies: 0
    Last Post: May 5th, 06:41 PM
  3. Gradiant Guru - where r u?
    By Graham_Newman@adobeforums.com in forum Adobe Illustrator Macintosh
    Replies: 12
    Last Post: February 26th, 07:22 AM
  4. Really need HELP from a GURU
    By MyaTiX in forum ASP Database
    Replies: 7
    Last Post: December 23rd, 06:51 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139