Synon 2E and Plex Emporium by Lee Dare (A developer blog)

Why bad designs sucks! Hmmmm, As I suspected a couple of weeks ago once you open your eyes to a subject and commence blogging about it you have it constantly in the back of your mind. My post on bad systems design and planning has had this affect on me. I am minding my own business at my local quiz night when a question was read out by the quiz master or perhaps mistress as she is a lady. "What day of the week was Valentines Day in the year 2000?" Now as I am not the romantic type so I certainly couldn't recall this answer based on an event, although a friend 'H' was adamant he knew the day. I decided the simple solution was the mobile phone calender so I plucked out the phone. It is a reasonably new Motorola Razor phone. So you know the routine, Menu, Organiser & Tools, Calendar. Voila.... The calendar is showing February 2009 (the current month when this event occurred). "Excellent", I said (I remember the excitement), I can now work it out by coun...

SELRCD - Synon 2e Development Standards Update: 05/12/2025 - I have created a page for all standards related posts. https://leedare-plex2e.blogspot.com/2025/12/synon-standard-posts-all-in-one-page.html Part 2 in the series around screen function types will concentrate on the Select Record (SELRCD) function type. This is often overlooked as a valuable function as it always appears to be generated on your behalf by 2e when you create a file. However, it has a few useful quirks that require a little thinking and I have often seen everly complicated logic added to them due to a lack of understanding where a simple workaround works quite nicely. Below I summarise some of the key points when using the SELRCD:- In general there should only be one SELRCD record per file, the default. I propose you rename your default select per for to '*SLT filename' . (See posts on naming standards). However, there may be occasions when it is necessary to select by a variety of different styles, or b...

Why bad design sucks! There are many areas of computing that have been let down by poor design. Actually that may be a little harsh. However, poor assumptions have definitely led to numerous designs that in hindsight could be considered questionable at best. These decisions have in turn led to systems that have suffered due to higher than anticipated volumes or longer than expected life spans. A few examples that come to mind are:- The millennium bug. Everyone knows this story. Developers designed systems in the 60s, 70s and 80s with 6 character dates ie DDMMYY or MMDDYY. The assumption being that storage is expensive and this system won't be around in 20 or 30 years. Well we all know how much effort was involved ensuring that airplanes never fell out of the sky in the late 90's, not to mention the contract rates for COBOL programmers that went with it. So I guess the lesson learned here is short sightedness. http://www.trademe.co.nz/ . Another example I heard about was for a ...