Results 1 to 21 of 21

Thread: User Interface for VB6 Forms

  1. #1

    Thread Starter
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    6,603

    User Interface for VB6 Forms

    Here's one I've struggled with through the years. I'm not really talking about whether we should use menu, buttons, or maybe ribbons. That's another discussion.

    What I'd like to discuss in this thread is a general approach to the actual function of a VB6 program's UI. As I see it, there are two approaches (with the second having two sub-approaches):
    1. Make extensive use of the .Enabled property (and maybe even the .Visible property) of various control, setting it to an appropriate value depending on the situation.
    2. Whenever a button (or checkbox or option button or whatever) is clicked, check things to see if it's reasonable for that option to be clicked. And, if it's not reasonable, possibly warn the user that they're doing something unreasonable. And the second sub-approach is just to do nothing if what they're doing is unreasonable (i.e., no warning).


    Let me use the little PNG/TGA Editing Tool I recently placed into the CodeBank as an example. Here's the latest "Main Menu" for it:

    Name:  WithTouchup.jpg
Views: 475
Size:  18.5 KB

    Now, we see that there's a "Save" (and "Save As...") button. However, it's unreasonable to click these buttons if a picture file isn't loaded. In the same vain, there's a "Touch Up" button. However, what if the user is choosing to not display any of the R,G,B,A images (which are the only places that touch up is allowed)? In that case, how should a click of that "Touch Up" button be handled?

    I can tell you that, through the years, I've used a combination of approaches. Typically, I start out using approach #1. However, as things evolve, that approach often gets difficult, especially when there's a UI that can be in several different states. Therefore, when I come back 6 months later to make some enhancements, I can't easily sort it all out, so I start resorting to approach #2, so I can get my work done.

    I just thought it would be interesting to hear the thoughts of others on this topic.

    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.

  2. #2
    PowerPoster Arnoutdv's Avatar
    Join Date
    Oct 2013
    Posts
    4,601

    Re: User Interface for VB6 Forms

    I also have a mix of 1. and 2.
    When possible I try to disable menu options which can't be used in the current context.
    In more ambiguous situations I evaluate it in the "click" or whatever event and give a message when the action is not viable at the moment.

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

    Re: User Interface for VB6 Forms

    In almost all cases where there can be multiple choices by the user and some sort of "Submit" action is needed, and some of those can conflict, I build a Validation routine. That routine is triggered on the "Submit" action and ensures required items are filled in correctly and that conflicting items are identified. If any issues were detected a message is displayed explaining the problem, typically something like: item x is required but wasn't provided, etc. Sounds like this approach is similar to what Arnoutdv was suggesting.

    For items that are mutually exclusive, those are fairly easy. When one is enabled/visible then the other isn't.
    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}

  4. #4

    Thread Starter
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    6,603

    Re: User Interface for VB6 Forms

    Quote Originally Posted by LaVolpe View Post
    That routine is triggered on the "Submit" action and ensures required items are filled in correctly and that conflicting items are identified.
    Ahhh, yes. That's also a standard for me. Yes, I have "Save" and "Save and Close" type buttons all over my primary application. And, almost without exception, I do several validations to make sure the user hasn't borked something about the data they've provided. That's all almost at another level from what I was talking about as well.

    I was actually being rather simplistic in my question. For instance, in my PNG/TGA editor, if they haven't loaded a file, how should the "Save" button be handled? Disabled? Enabled but a message popping up that says "No file loaded to save."? Even in that little program, things got complicated, and the frmMain has a procedure named EnableAppropriateControls, which is called every time something about the program status changes. And even that procedure was getting a bit unwieldy.

    It would have been easier to just check the status within each control, making sure it was appropriate to do what the user was trying to do (i.e., my #2 approach).

    I guess, I was just really asking, "how hard do people think we should work to disable controls when they're not appropriate?" It just often quickly gets to be problematic to do that, and it also makes the code difficult to figure out down the road.

    Thanks,
    Elroy

    EDIT1: Maybe it's all just a personal preference, and there's no best answer.
    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.

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

    Re: User Interface for VB6 Forms

    Yeah, that can get really complicated. Don't know if it's helpful, but in one project so many years ago, I tried to tackle it a different way. I created bit masks. A Long variable can handle 32 on/off values, 1 per bit. Several masks could be used as needed. As updates to states were needed, I set/cleared a bit related to that control and sent the mask to a routine that simply used the bit for enabled, visible, locked, checked, and/or other property values. That made it more manageable, but did require documenting which bits related to which controls so when you revisited it a 6 months later, you knew what the heck you were doing
    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}

  6. #6
    Frenzied Member
    Join Date
    Aug 2010
    Location
    Canada
    Posts
    1,792

    Re: User Interface for VB6 Forms

    Here's a slightly different opinion, at least for certain situations. I think the amount of work you do to disable/hide/whatever controls should be dependent on how much time and cognitive load you are saving the user.

    For example, you might hide buttons completely until certain conditions are met, but then the user might not know those options exist unless they read the documentation (and let's face it that's doesn't happen often enough!). The good part though is that everything that is not usable is completely out of the way, reducing distractions.

    Instead, you might disable buttons until the right conditions exist. So now users know there's an interesting looking feature, but perhaps they don't know how to get it activated (again unless they are motivated enough to delve into the documentation).

    I think sometimes the right decision though is to leave a button enabled and let them click it. In the click event you can test whether all the right conditions are met, and if so you can perform the action, or if not you now have a chance to show a message and explain what they need to do to perform the selected action. IMHO this increases discoverability, and is a good choice at times that you can prompt users to select and option that will ensure the required state exists for the feature to proceed.

    One problem though is that people often ignore message boxes (almost as much as they ignore documentation), but you at least get some who will read them and be better off with this approach.

    For the rest (save a final stubborn few for which there may be no help!) another approach is to use Task Dialogs. These may only work where one or two conditions are required to meet the requirements of the clicked action, but I've found they can be very helpful. Users tend to read them more often than plain old messages boxes with "Yes", "No', "Cancel" buttons.

    For example, let's say you have a button to update a row in a grid with some summary information, but in order to work that row has to be linked back to another grid. In this particular case, the row the user wants to have summarized has not been linked to anything. You can either:

    • Hide the summarize button, and they might not know that feature exists.
    • Disable the summarize button, and they will try clicking it and wonder why it doesn't work, or wonder how to get it to be enabled.
    • Keep the summarize button visible and enabled, and when clicked show a message like this:

      Name:  summary_messagebox.jpg
Views: 443
Size:  18.5 KB

    • Keep the summarize button visible and enabled, and when clicked show a Task Dialog like this:

      Name:  summary_taskdialog.jpg
Views: 438
Size:  25.1 KB


    In my experience, I get fewer support requests taking the TaskDialog approach in these scenarios, and users are even less likely to accidentally select the wrong option when compared with Yes/No or OK/Cancel Message Boxes.

    The Task Dialog can also save users' time - sometimes the steps they would have to take might be a few clicks away, but choosing a single Task Dialog option can take them directly to where they need to be (or in some cases simply perform the required steps for them).
    Last edited by jpbro; Apr 23rd, 2018 at 04:02 PM.

  7. #7

    Thread Starter
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    6,603

    Re: User Interface for VB6 Forms

    Quote Originally Posted by jpbro View Post
    I think sometimes the right decision though is to leave a button enabled and let them click it. In the click event you can test whether all the right conditions are met, and if so you can perform the action, or if not you now have a chance to show a message and explain what they need to do to perform the selected action. IMHO this increases discoverability, and is a good choice at times that you can prompt users to select and option that will ensure the required state exists for the feature to proceed.
    That's an excellent point, jpbro. I think maybe I was looking for a good rationale for not messing with .Enable=False, and I think you just gave it to me. I mean, it's sort of "cute" when buttons are disabled that aren't applicable, but it gets to be a PITA to keep the programming straight when things get complex.

    Thanks,
    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.

  8. #8
    Hyperactive Member
    Join Date
    Jun 2015
    Posts
    466

    Re: User Interface for VB6 Forms

    [...]
    Last edited by dz32; Apr 26th, 2019 at 11:22 AM.

  9. #9
    Fanatic Member
    Join Date
    May 2014
    Location
    Kallithea Attikis, Greece
    Posts
    1,013

    Re: User Interface for VB6 Forms

    1. Sometimes a flag can be used to stop second press in control, without using handle to enable property. All you have is to place a static variable type boolean, say it "once" and place an "if once then exit sub", then "once=true" and at the last point before exit another line "once=false". This way stop as second click, and there is no need to refresh the form/controls to draw control as disabled, and no need to code to rearrange the tab stop.
    2. It is important for the user to have feedback, so a status indicator as label or something more complicated, can be used.
    3. Don't forget the DoEvents. Code that running for a while has to use DoEvents to prevent os to get mad, and pop a white screen and choose to end the program. One way to have a nice own DoEvents can be done with the use of timegettime function, to perform DoEvents at standard intervals. This is not indicated for short time event service subs. When own doevents apply we have for the current sub to use the blocking flag, or maybe a set of blocking flags, or a utility sub to disable/enable a desired set of controls.
    4. A lot of controls can be very heavy for following and maybe user can reject the program for "difficulty". A list box, or better a drop down list, with offered "operations" maybe a more compact way to interact with user, and can be altered at times, when some operations can't be chosen.
    5. It's nice to have a full screen rather than a form of specific dimensions, and ratio of them, of our choice. This has the benefits to force us to have a float design. Also we get the option in a later upgrade to make this one user control, and if we wish to place it in a child form in an MDI application, with resize option. We have to use dpi for axis, and a function to magnify the output, so out dialog can be used independent from user's monitor arrangement.

    Elroy's all in one dialog method is not good for me. My proposal here is to distinguish the information labels from the input controls, using dialogs for input. So when an input chosen, we can see a dialog with places for new values and in labels the old values. At return to main form, we can see the "Status" of our choice. Two inputs can be stay in main forms, the operation to perform, and an "execution" button

  10. #10
    You don't want to know.
    Join Date
    Aug 2010
    Posts
    4,578

    Re: User Interface for VB6 Forms

    Here's an interesting hybrid:

    Do (1) and disable buttons that don't make sense in the current context for things that are easy to check. Give them an explanatory tooltip that says something like, "This feature is currently disabled because...". That way you get the explanatory benefits of (2) along with the visible feedback of (1).

    It's not always possible, and it doesn't work for menu options so well (I don't think anyone expects those to have tooltips), but I think it strikes a balance.

    Another option not discussed is hiding banks of controls as modes change, but I think in the example we're working with that's impractical/not possible. Like (1), whether it makes sense to hide a control can be context sensitive.

    It also depends on the "user level" you're dealing with. Tools for professionals can get away with "I expect you to know what buttons can be pushed in which modes". Tools for beginners should be a bit more friendly, and seeing banks of stuff get disabled as they change modes can be a big help.

    Either way I think we all agree: if a control is disabled, it's very nice to be able to ask why and get an answer.
    This answer is wrong. You should be using TableAdapter and Dictionaries instead.

  11. #11

    Thread Starter
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    6,603

    Re: User Interface for VB6 Forms

    Quote Originally Posted by Sitten Spynne View Post
    Another option not discussed is hiding banks of controls as modes change
    That's always been a problem form me. Anytime I hide controls, I always get comments from my users like, "wow, I just did something the other day and saw a new option, and I never new I could do that because I had never done it that way before." And then, I also get the opposite complaint, "geez, this program does so much that we'll never do. Is there anyway to 'turn off' the stuff we'll never use?"

    Regarding that second one, I'll give an example. My program is capable of analyzing, storing, and reporting on O2 consumption during walking. However, many hospitals I deal with don't have the equipment for O2 measurement, so they'll never use that section.

    I've had to build a screen over in my "Maintenance" area that allows users to turn on/off many of the features of my program, just so users don't have to look at certain functionality everyday.

    However, to get back to the "hiding" option (other than by user's orders), I've just learned to stay away from that one except in very specific situations.

    The ToolTips idea isn't at all bad either. In fact, I often use ToolTips, and have a complex function for using API ToolTips, and use them often.

    All The Best,
    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.

  12. #12
    You don't want to know.
    Join Date
    Aug 2010
    Posts
    4,578

    Re: User Interface for VB6 Forms

    Yeah, don't get me wrong. For a lot of this stuff there's no "right" answer and the art is figuring out which users that will complain are the users you don't mind complaining Like, just on that example above I could say a bunch of things, but none of them are 100% "I think you'd be better off if you did them".

    I was going to make some examples, but then I realized what I'm looking at isn't the app itself, but a kind of pseudo-ribbon. You'd probably expect me to yell about that but actually it's pretty clever. This is probably an "expert" application for people who know what they're doing, and my experience is that level of user tends to appreciate "hard to learn but fast to use" UI over "intuitive but clunky".

    Point of Sale software's a good example. The "easy" interface has maybe a number pad for entry. This asks operators to learn the price for items and manually enter them. It's hard to get faster at it. The "better" interface has a bunch of buttons with giant pictures of the items. But if you look at a lot of POS software, it doesn't even bother with pictures. It turns out the operators, over time, gain muscle memory for where the right buttons are, and the pictures only serve to slow them down!

    Now that I understand that example more, yeah, hiding those controls is too jarring.
    This answer is wrong. You should be using TableAdapter and Dictionaries instead.

  13. #13
    Hyperactive Member
    Join Date
    Mar 2018
    Posts
    445

    Re: User Interface for VB6 Forms

    I use both .enabled and message boxes but tend to prefer .enabled. It makes for less clicks and avoids jarring popups.

    I've also noticed that I rarely get questions about why something is disabled but get lots of questions about my popups. Even simple things like "That name is already used, choose a different name and try again" will get a question like "why can't I create the thing with this name" with a nice screenshot of the message

  14. #14
    PowerPoster
    Join Date
    Feb 2006
    Posts
    22,532

    Re: User Interface for VB6 Forms

    Disabling inapplicable controls by mode works... until it doesn't. Sometimes hiding and showing panels of controls as modes change doesn't really have a good alternative. Look at how the Ribbon control works for example. Without hiding/showing it'd eat a lot of screen real estate to hold all of the possible twiddlable options.

  15. #15
    Frenzied Member jdc2000's Avatar
    Join Date
    Oct 2001
    Location
    Idaho Falls, Idaho USA
    Posts
    1,871

    Re: User Interface for VB6 Forms

    One thing that really annoys me about Microsoft's Ribbon, aside from the fact that it eats up a lot of screen real estate, is that it will sometimes change from the item group I have selected to a different group when I click on something. Then I just have to change it back again. It also takes a lot more mouse movement and clicks to get to something then the old menu interface did.

  16. #16
    You don't want to know.
    Join Date
    Aug 2010
    Posts
    4,578

    Re: User Interface for VB6 Forms

    One thing the Ribbon gets right, is very cool, and mysteriously didn't carry over to the Ribbon on their Mac apps: If you hold CTRL, every ribbon control displays a tooltip showing you which key is the shortcut for that ribbon key. It turns out they put a lot of work into ensuring you can actually navigate the entire Office ribbon with the keyboard alone.

    I think the ribbon's fate is that of many fancy UI choices. It's harder to write "a bad drop-down menu" than "a bad ribbon". Since the ribbon takes up so much real estate, and monitors stopped getting better once "HD" became a buzzword, it sort of has to deliver more value for what it does. It's REALLY hard to get it right. So it's almost always interpreted as wrong. Maybe it'd have been nicer if it had an auto-hide behavior so it didn't "cost" so much. I think I'm finally settling on the idea it was a neat idea, but not one as good as its simpler alternatives.
    This answer is wrong. You should be using TableAdapter and Dictionaries instead.

  17. #17
    Hyperactive Member
    Join Date
    Mar 2018
    Posts
    445

    Re: User Interface for VB6 Forms

    Quote Originally Posted by Sitten Spynne View Post
    Maybe it'd have been nicer if it had an auto-hide behavior so it didn't "cost" so much
    google "auto-hide ribbon" and be amazed

  18. #18
    You don't want to know.
    Join Date
    Aug 2010
    Posts
    4,578

    Re: User Interface for VB6 Forms

    Oh, I know you can do it, but it's not the default behavior. The rule of thumb for "less experienced users" is they never change the defaults. I can imagine a lot of the initial backlash towards the ribbon involved people seeing less of their screen than they were used to, and wonder if it had used auto-hide by default they might have seen it as "a neater menu" instead of "this thing that occupies 10% of my space".

    I don't know. There's something about the Vista era where users got really hostile towards every MS change and that's a really thorny discussion.
    This answer is wrong. You should be using TableAdapter and Dictionaries instead.

  19. #19
    Hyperactive Member
    Join Date
    Mar 2018
    Posts
    445

    Re: User Interface for VB6 Forms

    Quote Originally Posted by Sitten Spynne View Post
    Oh, I know you can do it, but it's not the default behavior. The rule of thumb for "less experienced users" is they never change the defaults. I can imagine a lot of the initial backlash towards the ribbon involved people seeing less of their screen than they were used to, and wonder if it had used auto-hide by default they might have seen it as "a neater menu" instead of "this thing that occupies 10% of my space".

    I don't know. There's something about the Vista era where users got really hostile towards every MS change and that's a really thorny discussion.
    Users hate change and vista\ribbons\etc were all big departures. Performance was also bad. I've seen enough toolbar filled browsers to know that there are many people don't care about space. Because once you remove them, they will complain about you "messing it up"

  20. #20
    You don't want to know.
    Join Date
    Aug 2010
    Posts
    4,578

    Re: User Interface for VB6 Forms

    I think it's worth pointing out that what MS probably failed to realize and, worse, failed to articulate, is that ribbons only do a good thing in certain cases and not every application should use one instead of menus and toolbars.

    I keep looking at that screenshot Elroy posted and it is a good Ribbon. There's not a good way to do the gamma/brightness/contrast settings as he did in normal menus and toolbars. I can think of clunky ways to do it, but without his work here it'd probably be best to display it all in a tool window.

    That's when a Ribbon works: 'This is a tool window that everyone has displayed 99% of the time.' Very few apps find themselves in that scenario. So I can't blanket-reject Ribbon UI, but it's definitely overrated.

    I think Elroy hit on something though: if you ARE designing a Ribbon UI, it's confusing to have bits of it that are context-sensitive. So you need to put a lot of thought into how you convey that.
    This answer is wrong. You should be using TableAdapter and Dictionaries instead.

  21. #21

    Thread Starter
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    6,603

    Re: User Interface for VB6 Forms

    Quote Originally Posted by Sitten Spynne View Post
    The rule of thumb for "less experienced users" is they never change the defaults.
    That is so true. It's even true for very experienced users.

    Personally, on my development powerhouse laptop, I have almost every program tweaked to my liking, with notes on what I did so I can re-do it when I upgrade my machine.

    However, all of my users are in hospital settings. As such, it's often the case where multiple people work on a single workstation. And also, the actual computer boxes are frequently swapped around by I.T. As such, there's just no use in tweaking settings. You're liable to lose them the next time you sit down. And, through the years, the I.T. departments have slowly learned how to crank down the policy settings such that they can't be changed anyway.

    Therefore, as I often sit down at one of these workstations, I too have learned the "defaults". So Sitten, you're right. The initial installation "default" behavior is important.

    Best Regards,
    Elroy
    Last edited by Elroy; Apr 26th, 2018 at 11:46 AM.
    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.

Posting Permissions

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



Click Here to Expand Forum to Full Width