dcsimg
Results 1 to 36 of 36
  1. #1

    Thread Starter
    Member
    Join Date
    Jul 2016
    Posts
    52

    Any technical reason not to use Call in VB6?

    Hey

    If you know of any technical reasons why one should not call functions using "Call" in VB6 other than because its deprecated, I'd like to hear them.

  2. #2
    Fanatic Member
    Join Date
    Jun 2012
    Posts
    986

    Re: Any technical reason not to use Call in VB6?

    It's not needed. (Technically)

    I have the habbit to use 'Call' when calling an own custom Sub method. Else when calling an function or API I use without 'Call'.
    But that's just a personal habbit and no technically need.
    I think it is some very old Basic keyword that is supported to mantain compatibility..

  3. #3

  4. #4

    Thread Starter
    Member
    Join Date
    Jul 2016
    Posts
    52

    Re: Any technical reason not to use Call in VB6?

    Good example. To me, that's more of a reason not to use reserved words in VB6 than a reason for using "Call" - not only because using reserved words could make reading code confusing, but also because chaos will ensue regarding capitalization in your diffs. For example, let's say you use a variable called "index" (lowercase), or "x" (lowercase), then add a sub for a _MouseMove event... VB will change the case of some (not necessarily all) instances of your variables in completely unrelated routines just because you added the _MouseMove sub, leading to a complete mess in the diff and trouble merging with other team members.

  5. #5
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    32,188

    Re: Any technical reason not to use Call in VB6?

    Thread moved from CodeBank, which is for finished code snippets rather than questions.
    My usual boring signature: Nothing

  6. #6
    Fanatic Member
    Join Date
    Dec 2012
    Posts
    576

    Re: Any technical reason not to use Call in VB6?

    I personally use "Call" a lot. Most sub routines I write as functions returning a Boolean True or False. Using the "Call" word allows me to ignore that value. If I want to verify success of the routine, I can check the return value. It gives me more options.

    J.A. Coutts

  7. #7
    PowerPoster
    Join Date
    Feb 2006
    Posts
    18,921

    Re: Any technical reason not to use Call in VB6?

    You don't need to use the archaic Call statement to invoke a Function.

  8. #8
    Addicted Member
    Join Date
    Feb 2017
    Posts
    205

    Re: Any technical reason not to use Call in VB6?

    My personal preference has always been to use call.
    I find it helps to quickly ID a procedure when reviewing code,
    and hence give me a mental roadmap of where I'm at.

  9. #9
    Fanatic Member
    Join Date
    Jan 2013
    Posts
    624

    Re: Any technical reason not to use Call in VB6?

    "Call" is no more deprecated than any other bit of VB "Proper".

    Personally, I use Call because I also work with other languages where the the use of brackets is required.
    It makes shifting from one language to another [slightly] less jarring.

    Regards, Phill W.

  10. #10
    Super Moderator RobDog888's Avatar
    Join Date
    Apr 2001
    Location
    LA, Calif. Raiders #1 AKA:Gangsta Yoda™
    Posts
    60,555

    Re: Any technical reason not to use Call in VB6?

    Call has been considered "bad" to use not from a technical standpoint but rather from a good coding standard/syntax. I haven't used it since the days of BASIC.
    VB/Office Guru™ (AKA: Gangsta Yoda®)
    I dont answer coding questions via PM. Please post a thread in the appropriate forum.

    Microsoft MVP 2006-2011
    Office Development FAQ (C#, VB.NET, VB 6, VBA)
    Senior Jedi Software Engineer MCP (VB 6 & .NET), BSEE, CET
    If a post has helped you then Please Rate it!
    Star Wars Gangsta Rap Reps & Rating PostsVS.NET on Vista Multiple .NET Framework Versions Office Primary Interop AssembliesVB/Office Guru™ Word SpellChecker™.NETVB/Office Guru™ Word SpellChecker™ VB6VB.NET Attributes Ex.Outlook Global Address ListAPI Viewer utility.NET API Viewer Utility
    System: Intel i7 6850K, Corsair H100i v2 water cooler, Geforce GTX1060, Samsung M.2 500 GB & SATA 500 GB, 32 GBs DDR4 3300 Quad Channel RAM, 2 Viewsonic 24" LCDs, Windows 10, Office 2010, VS 2010

  11. #11
    Frenzied Member
    Join Date
    Jun 2015
    Posts
    1,999

    Re: Any technical reason not to use Call in VB6?

    Quote Originally Posted by Phill.W View Post
    "Call" is no more deprecated than any other bit of VB "Proper".

    Personally, I use Call because I also work with other languages where the the use of brackets is required.
    It makes shifting from one language to another [slightly] less jarring.

    Regards, Phill W.
    That's why I used to use it.
    Imagine what it would be like to set breakpoints in, or step through subclassing code;
    and then being able to hit stop/end/debug or continue, without crashing the IDE.

    VB6.tlb | Bulletproof Subclassing in the IDE (no thunks/assembly/DEP issues)

  12. #12
    Fanatic Member
    Join Date
    Dec 2014
    Posts
    622

    Re: Any technical reason not to use Call in VB6?

    is there any difference in the compiled executable when using "call" to call a function?

  13. #13
    PowerPoster techgnome's Avatar
    Join Date
    May 2002
    Posts
    31,681

    Re: Any technical reason not to use Call in VB6?

    There's no technical reason to not use it just as there's no technical reason to use it. It's purely aesthetic and personal. I personally find it superfluous and unnecessary. To me, it just creates noise that I find distracting. Of course I'm calling something. VB is already verbose enough on it's own, I don't need to be adding optional keywords to my code.

    That said, I may find it irritating, noisy, and I may mention something to the coder, but that's as far as it's going to go. I'm not going to champion that they take them out, or hold it against them.

    -tg
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.*
    * I also don't respond to friend requests. Save a few bits and don't bother. I'll just end up rejecting anyways.*
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *

  14. #14
    Fanatic Member
    Join Date
    Jan 2013
    Posts
    624

    Re: Any technical reason not to use Call in VB6?

    None at all.

    Regards, Phill W.

  15. #15
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    4,384

    Re: Any technical reason not to use Call in VB6?

    To my eyes, this is just one of those "personal style" issues, that each programmer needs to decide for themselves. We may get dogmatic, defending our personal style, but, IMHO, that's just silliness.

    It's similar to...
    • whether or not to indent the "Case" statements in a "Select Case" block.
    • whether it's essential that all constants be capitalized.
    • whether procedure comments should be place before or after the first procedure definition line.
    • whether we should prefix all control names with txt, cbo, lbl, etc.
    • whether we should use "Dim" vs "Private" with module level variable declarations.
    • whether or not we should be allowed to put two (or three, or more) statements on a single line with the colon.
    • etcetera etcetera.


    Certainly, there are some things that actually make a difference, but I don't think any of the ones I've listed make one iota of difference, except for the visual appearance of the source code.

    It's just a matter of style, and we'll always each have our own. And, a bit of flexibility in this regard may not be all bad.

    Best Regards,
    Elroy

    EDIT1: Just to say it before someone else does, yeah, a single-line "If" statement will compile a bit differently than a multi-line "If". But that's not exactly what I meant.
    Last edited by Elroy; Jan 12th, 2018 at 01:41 PM.
    Any software I post in these forums written by me is provided “AS IS” without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. Please understand that I’ve been programming since the mid-1970s and still have some of that code. My contemporary VB6 project is approaching 1,000 modules. In addition, I have a “VB6 random code folder” that is overflowing. I’ve been at this long enough to truly not know with absolute certainty from whence every single line of my code has come, with much of it coming from programmers under my employ who signed intellectual property transfers. I have not deliberately attempted to remove any licenses and/or attributions from any software. If someone finds that I have inadvertently done so, I sincerely apologize, and, upon notice and reasonable proof, will re-attach those licenses and/or attributions. To all, peace and happiness.

  16. #16
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    17,341

    Re: Any technical reason not to use Call in VB6?

    Agreed... a personal choice. My preference is to use it for subroutines that have no parameters or a function with no parameters and I don't care about the return value. I typically don't like to see a single function/sub name on a line all by itself; it almost feels like some orphaned statement/code.

    For example: let's pretend we have a private subroutine called Cleanup
    Instead of: Cleanup
    I would typically use: Call Cleanup
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  17. #17
    Fanatic Member
    Join Date
    Feb 2017
    Posts
    890

    Re: Any technical reason not to use Call in VB6?

    Occam's razor

  18. #18

  19. #19
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    17,341

    Re: Any technical reason not to use Call in VB6?

    The trick: Call Foo((l2)) is same effect as Foo (l1).

    Not sure what you were trying to say with your sample code. I think most of us know the effect of enclosing byref parameters with parentheses?
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  20. #20
    Frenzied Member
    Join Date
    Jun 2015
    Posts
    1,999

    Re: Any technical reason not to use Call in VB6?

    Quote Originally Posted by LaVolpe View Post
    The trick: Call Foo((l2)) is same effect as Foo (l1).

    Not sure what you were trying to say with your sample code. I think most of us know the effect of enclosing byref parameters with parentheses?
    i think his point is that most of us actually don't
    and by "us" i mean the vast majority of the VB community, not us in this thread.

    I don't know any other language with a similar construct of creating a temp variable using parenthesis.
    Imagine what it would be like to set breakpoints in, or step through subclassing code;
    and then being able to hit stop/end/debug or continue, without crashing the IDE.

    VB6.tlb | Bulletproof Subclassing in the IDE (no thunks/assembly/DEP issues)

  21. #21

  22. #22
    PowerPoster
    Join Date
    Feb 2012
    Location
    West Virginia
    Posts
    12,334

    Re: Any technical reason not to use Call in VB6?

    I do not use the call keyword, haven't for many years. Can't even remember now where it was last required, VBDos maybe or maybe even before that. I know it has been at least 20 years since I felt the need to use it in any code and always cringe a little when I see someone else use it. Always expect to see them using the Let keyword as well

  23. #23
    Frenzied Member
    Join Date
    Dec 2008
    Posts
    1,118

    Re: Any technical reason not to use Call in VB6?

    I believe it makes the code more readable/understandable

  24. #24
    Fanatic Member
    Join Date
    Sep 2012
    Posts
    962

    Re: Any technical reason not to use Call in VB6?

    IMO, Call has the following functions
    (1) no return value
    (2) different from other lines of source code
    (3) play a role of emphasis
    (4) to make the source code a little more clear
    (5) and the meaning of nostalgia
    (6) to make the programming style diversified (this is a good thing and also a bad thing)
    (7) keep spaces on the left of a source code line

    Code:
    Sub Test()
    
    Method1: Method2 '// There is no space to the left of the code line
    
    **** Call Method1:    Method2 '// There is 4 spaces to the left of the code line
    
    End Sub
    However, I only use Call occasionally.
    Last edited by dreammanor; Jan 13th, 2018 at 08:32 AM.

  25. #25
    Fanatic Member
    Join Date
    Sep 2012
    Posts
    962

    Re: Any technical reason not to use Call in VB6?

    sorry, deleted the duplicate post.
    Last edited by dreammanor; Jan 13th, 2018 at 08:33 AM.

  26. #26
    Addicted Member
    Join Date
    Jun 2015
    Posts
    225

    Re: Any technical reason not to use Call in VB6?

    i use call once in a while if I am calling a sub with no arguments and want to make it clear that its a procedure call

  27. #27
    New Member
    Join Date
    Jan 2018
    Posts
    2

    Re: Any technical reason not to use Call in VB6?

    It's a personal choice with no right or wrong. I use Call only for better readability in my opinion. Calls to subroutines vs functions vs variable names stand out better. Yes, I know you can easily tell anyways but Call for me adds readability rather than degrades from it. Especially when explaining code snippets to non-programmers such as mechanical engineers.

    An old keyword that I doubt anyone still uses would be LET

  28. #28
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    4,384

    Re: Any technical reason not to use Call in VB6?

    Well, I ran across a good reason to use "Call" (and I was in the habit of not using it). If you're following threads, you'll know I've been dabbling in the GDI+. Almost all of these GDI+ APIs are "Functions". And, as such, they return either zero, or an error code. (Any returned pointers, etcetera, are returned in passed arguments and not as the function's return value.)

    However, I'm not one to go overboard on checking to make sure every step worked without error. To me, it just seems like WAY overkill. I mean, if the GDI+ initialized, why wouldn't it create a new image with a call to GdipCreateBitmapFromScan0? It just seems to clutter up code worrying about every possible error.

    But, here comes the catch. When I'm writing code, I may not have it entirely debugged on the first pass. For instance, I may try to set image attributes before I've created a hImgAttr handle. So, if I'm not checking for errors, how do I track this down?

    Simple, I use "Call" for all my API calls into the GDI+. And, when something has gone awry, I replace all these "Call" statements with a "MsgBox" statement. This allows me to basically step-through the code (with message boxes), and figure out what I've done wrong. And, if I hadn't used the "Call" convention, it'd be much harder to do this.

    Also, at some point, I might replace the "Call" statements with "Gdip_CheckForErrors" procedures. It's just a thought, a universal GDI+ error checker procedure.

    Just Saying,
    Elroy
    Any software I post in these forums written by me is provided “AS IS” without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. Please understand that I’ve been programming since the mid-1970s and still have some of that code. My contemporary VB6 project is approaching 1,000 modules. In addition, I have a “VB6 random code folder” that is overflowing. I’ve been at this long enough to truly not know with absolute certainty from whence every single line of my code has come, with much of it coming from programmers under my employ who signed intellectual property transfers. I have not deliberately attempted to remove any licenses and/or attributions from any software. If someone finds that I have inadvertently done so, I sincerely apologize, and, upon notice and reasonable proof, will re-attach those licenses and/or attributions. To all, peace and happiness.

  29. #29
    Frenzied Member
    Join Date
    Jun 2015
    Posts
    1,999

    Re: Any technical reason not to use Call in VB6?

    that's how the C++ class wrappers work. they save the last error code using SetStatus().

    Graphics.cls
    Code:
    Public Function DrawLineI(Pen As Pen, ByVal X1 As Long, ByVal Y1 As Long, ByVal X2 As Long, ByVal Y2 As Long) As GpStatus
        DrawLineI = SetStatus(DLLExports.GdipDrawLineI(m_nativeGraphics, Pen.NativePen, X1, Y1, X2, Y2))
    End Function
    Imagine what it would be like to set breakpoints in, or step through subclassing code;
    and then being able to hit stop/end/debug or continue, without crashing the IDE.

    VB6.tlb | Bulletproof Subclassing in the IDE (no thunks/assembly/DEP issues)

  30. #30
    Fanatic Member
    Join Date
    Sep 2012
    Posts
    962

    Re: Any technical reason not to use Call in VB6?

    Quote Originally Posted by Elroy View Post
    Well, I ran across a good reason to use "Call" (and I was in the habit of not using it). If you're following threads, you'll know I've been dabbling in the GDI+. Almost all of these GDI+ APIs are "Functions". And, as such, they return either zero, or an error code. (Any returned pointers, etcetera, are returned in passed arguments and not as the function's return value.)

    However, I'm not one to go overboard on checking to make sure every step worked without error. To me, it just seems like WAY overkill. I mean, if the GDI+ initialized, why wouldn't it create a new image with a call to GdipCreateBitmapFromScan0? It just seems to clutter up code worrying about every possible error.

    But, here comes the catch. When I'm writing code, I may not have it entirely debugged on the first pass. For instance, I may try to set image attributes before I've created a hImgAttr handle. So, if I'm not checking for errors, how do I track this down?

    Simple, I use "Call" for all my API calls into the GDI+. And, when something has gone awry, I replace all these "Call" statements with a "MsgBox" statement. This allows me to basically step-through the code (with message boxes), and figure out what I've done wrong. And, if I hadn't used the "Call" convention, it'd be much harder to do this.

    Also, at some point, I might replace the "Call" statements with "Gdip_CheckForErrors" procedures. It's just a thought, a universal GDI+ error checker procedure.

    Just Saying,
    Elroy
    Golang allows functions to return multiple values. That feature is useful.

  31. #31
    Fanatic Member
    Join Date
    Dec 2012
    Posts
    576

    Re: Any technical reason not to use Call in VB6?

    Quote Originally Posted by Elroy View Post
    Well, I ran across a good reason to use "Call" (and I was in the habit of not using it). If you're following threads, you'll know I've been dabbling in the GDI+. Almost all of these GDI+ APIs are "Functions". And, as such, they return either zero, or an error code. (Any returned pointers, etcetera, are returned in passed arguments and not as the function's return value.)
    Elroy
    Pretty much what I said back in post 6, although I didn't explain it in as much depth.

    J.A. Coutts

  32. #32
    PowerPoster
    Join Date
    Feb 2006
    Posts
    18,921

    Re: Any technical reason not to use Call in VB6?

    Quote Originally Posted by Elroy View Post
    However, I'm not one to go overboard on checking to make sure every step worked without error. To me, it just seems like WAY overkill. I mean, if the GDI+ initialized, why wouldn't it create a new image with a call to GdipCreateBitmapFromScan0? It just seems to clutter up code worrying about every possible error.
    This extra effort is why we have the HRESULT-driven exception mechanism for COM member calls: it makes for more compact coding and less disruption of logical flow in your source code. Of course that's only viable if you do proper exception handling and take appropriate actions unless you are willing to have exceptions terminate your program.

    What errors?

    Code:
    Private Enum GpStatus
        Ok = 0
        GenericError = 1
        InvalidParameter = 2
        OutOfMemory = 3
        ObjectBusy = 4
        InsufficientBuffer = 5
        NotImplemented = 6
        Win32Error = 7
        WrongState = 8
        Aborted = 9
        FileNotFound = 10
        ValueOverflow = 11
        AccessDenied = 12
        UnknownImageFormat = 13
        FontFamilyNotFound = 14
        FontStyleNotFound = 15
        NotTrueTypeFont = 16
        UnsupportedGdiplusVersion = 17
        GdiplusNotInitialized = 18
        PropertyNotFound = 19
        PropertyNotSupported = 20
    End Enum
    What you suggest is the same as putting On Error Resume Next at the head of every procedure. Not a good idea ever, and in this case you risk GDI+ and GDI object leaks, memory leaks of other kinds, data corruption, etc.


    I fail to see how any of that relates to use of the obsolete and eye-jarring Call statement left over from ancient Microsoft Basic dialects. If you want to ignore the returned result then you can use the proper subroutine call syntax that was added long ago to treat subroutines as verbs. I don't expect anyone to change his mind based on my recommendation though.

  33. #33
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    4,384

    Re: Any technical reason not to use Call in VB6?

    Quote Originally Posted by dilettante View Post
    I don't expect anyone to change his mind based on my recommendation though.

    ----
    Any software I post in these forums written by me is provided “AS IS” without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. Please understand that I’ve been programming since the mid-1970s and still have some of that code. My contemporary VB6 project is approaching 1,000 modules. In addition, I have a “VB6 random code folder” that is overflowing. I’ve been at this long enough to truly not know with absolute certainty from whence every single line of my code has come, with much of it coming from programmers under my employ who signed intellectual property transfers. I have not deliberately attempted to remove any licenses and/or attributions from any software. If someone finds that I have inadvertently done so, I sincerely apologize, and, upon notice and reasonable proof, will re-attach those licenses and/or attributions. To all, peace and happiness.

  34. #34
    Super Moderator RobDog888's Avatar
    Join Date
    Apr 2001
    Location
    LA, Calif. Raiders #1 AKA:Gangsta Yoda™
    Posts
    60,555

    Re: Any technical reason not to use Call in VB6?

    Using Call is just uncalled for
    VB/Office Guru™ (AKA: Gangsta Yoda®)
    I dont answer coding questions via PM. Please post a thread in the appropriate forum.

    Microsoft MVP 2006-2011
    Office Development FAQ (C#, VB.NET, VB 6, VBA)
    Senior Jedi Software Engineer MCP (VB 6 & .NET), BSEE, CET
    If a post has helped you then Please Rate it!
    Star Wars Gangsta Rap Reps & Rating PostsVS.NET on Vista Multiple .NET Framework Versions Office Primary Interop AssembliesVB/Office Guru™ Word SpellChecker™.NETVB/Office Guru™ Word SpellChecker™ VB6VB.NET Attributes Ex.Outlook Global Address ListAPI Viewer utility.NET API Viewer Utility
    System: Intel i7 6850K, Corsair H100i v2 water cooler, Geforce GTX1060, Samsung M.2 500 GB & SATA 500 GB, 32 GBs DDR4 3300 Quad Channel RAM, 2 Viewsonic 24" LCDs, Windows 10, Office 2010, VS 2010

  35. #35
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    4,384

    Re: Any technical reason not to use Call in VB6?

    Ok ok ok.

    I built this little function that I now use. I replaced all my "Call" statements with that little "Retn" procedure, all all for dilettante.

    Code:
    
    Private Sub Retn(GdipReturn As Long)
        ' Just to check for any errors.
        '
        If GdipReturn = Ok Then Exit Sub
        If Not InIde6 Then Exit Sub
                                            Debug.Print "GDI+ Error:  ";
        Select Case GdipReturn
        Case GenericError:                  Debug.Print "Generic Error"
        Case InvalidParameter:              Debug.Print "Invalid Parameter/Argument"
        Case OutOfMemory:                   Debug.Print "Out Of Memory"
        Case ObjectBusy:                    Debug.Print "Object Busy, already in use in another thread"
        Case InsufficientBuffer:            Debug.Print "Insufficient Buffer, buffer specified as an argument in the API call is not large enough"
        Case NotImplemented:                Debug.Print "Method Not Implemented"
        Case Win32Error:                    Debug.Print "Win32 Error"
        Case WrongState:                    Debug.Print "Wrong State"
        Case Aborted:                       Debug.Print "Method Aborted"
        Case FileNotFound:                  Debug.Print "File Not Found"
        Case ValueOverflow:                 Debug.Print "Value Overflow, arithmetic operation that produced a numeric overflow"
        Case AccessDenied:                  Debug.Print "Access Denied"
        Case UnknownImageFormat:            Debug.Print "Unknown Image Format"
        Case FontFamilyNotFound:            Debug.Print "Font Family Not Found"
        Case FontStyleNotFound:             Debug.Print "Font Style Not Found"
        Case NotTrueTypeFont:               Debug.Print "Not TrueType Font"
        Case UnsupportedGdiplusVersion:     Debug.Print "Unsupported Gdiplus Version"
        Case GdiplusNotInitialized:         Debug.Print "Gdiplus Not Initialized"
        Case PropertyNotFound:              Debug.Print "Property Not Found, does not exist in the image"
        Case PropertyNotSupported:          Debug.Print "Property Not Supported, not supported by the format of the image"
        Case ProfileNotFound:               Debug.Print "Profile Not Found, color profile required to save an image in CMYK format was not found"
        Case Else:                          Debug.Print "Error Not Specified"
        End Select
        '
        Stop
    End Sub
    
    
    Y'all Take Care,
    Elroy
    Any software I post in these forums written by me is provided “AS IS” without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. Please understand that I’ve been programming since the mid-1970s and still have some of that code. My contemporary VB6 project is approaching 1,000 modules. In addition, I have a “VB6 random code folder” that is overflowing. I’ve been at this long enough to truly not know with absolute certainty from whence every single line of my code has come, with much of it coming from programmers under my employ who signed intellectual property transfers. I have not deliberately attempted to remove any licenses and/or attributions from any software. If someone finds that I have inadvertently done so, I sincerely apologize, and, upon notice and reasonable proof, will re-attach those licenses and/or attributions. To all, peace and happiness.

  36. #36
    Super Moderator RobDog888's Avatar
    Join Date
    Apr 2001
    Location
    LA, Calif. Raiders #1 AKA:Gangsta Yoda™
    Posts
    60,555

    Re: Any technical reason not to use Call in VB6?

    Private Sub ElReturn(GdipReturn As Long)
    VB/Office Guru™ (AKA: Gangsta Yoda®)
    I dont answer coding questions via PM. Please post a thread in the appropriate forum.

    Microsoft MVP 2006-2011
    Office Development FAQ (C#, VB.NET, VB 6, VBA)
    Senior Jedi Software Engineer MCP (VB 6 & .NET), BSEE, CET
    If a post has helped you then Please Rate it!
    Star Wars Gangsta Rap Reps & Rating PostsVS.NET on Vista Multiple .NET Framework Versions Office Primary Interop AssembliesVB/Office Guru™ Word SpellChecker™.NETVB/Office Guru™ Word SpellChecker™ VB6VB.NET Attributes Ex.Outlook Global Address ListAPI Viewer utility.NET API Viewer Utility
    System: Intel i7 6850K, Corsair H100i v2 water cooler, Geforce GTX1060, Samsung M.2 500 GB & SATA 500 GB, 32 GBs DDR4 3300 Quad Channel RAM, 2 Viewsonic 24" LCDs, Windows 10, Office 2010, VS 2010

Posting Permissions

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



Featured


Click Here to Expand Forum to Full Width