Hypothetical for Microsoft and other Software Companies

Since my Windows XP computer died, I have been finding using a computer more and more irritating, everything seems to be going backwards. The same goes for digital TV: analogue TV was getting close to perfection, so it seems someone decided to break it by cutting the analogue signal and forcing everyone over to unstable and less robust digital TV broadcasts. I say less robust because when an analogue signal is poor, still likely to get a snowy picture and gain some information. When a digital signal is poor, then get pixelated garbage. Digital TV was imposed by government without any democratic vote on the matter. It however is an infrastructure issue. Computer hardware and the software that runs on it, however is not an infrastructure issue. There is no good reason to remove one technology from the market and replace it with an alternative.

As I have mentioned previously the different versions of MS Windows are not upgrades, they are different products. If the software that I had running on Windows XP will not run on Windows 7 or Windows 10, then it clearly is not an upgrade. If the user interface changes and operation changes then its different not an upgrade. A power driver is not an upgrade of a ordinary screwdriver, it represents a single optimised function and single capability of an ordinary screwdriver. A power driver is less useful than an ordinary screwdriver. Likewise as another example a nail gun is not an upgrade of a hammer, it also is less useful than an ordinary hammer.

So my problem. My hardware fails, and my software is locked by OEM licensing to the failed device and I cannot get new hardware with required operating system. More importantly two of main software packages won't install or run under Windows 7 or Windows 10. I went with the upgrade to Windows 10, as I didn't like Windows 7 and my software didn't work anyway.

Proposal 1

If buy hardware from same manufacturer, then OEM license permitted to transfer to new hardware.

Proposal 2

Microsoft releases a new operating system, which contains pre-installed virtual boxes for all its previous operating systems.

Proposal 3

Microsoft releases Windows XP and Office 2003 under a GPL or similar license.

As far as I'm concerned this software worked perfectly fine out off the box. If a computer virus is something which interferes with and hinders being able to use a computer as intended: then Microsoft automatic updates are a computer virus. A computer does not need to be connected to the internet. Computer software does not need to be updated on a regular basis. Most people are not computer geeks or technology geeks, they are not waiting for the latest release, and they don't care about some tweak discovered by some geek. In the main they just want to get on with what they were doing or are doing. To have computer resources suddenly tied up by updates is not acceptable. To be unable to carry out a simple lookup on the internet because updates are being downloaded and consuming data allowance is not acceptable.

I understand, need to protect copyright, and need to keep selling something to make a living.

But here's the thing. Windows XP is massive operating system, compared to CPM/80 on a 360 kbyte floppy disk, or MS DOS on a 720 kbyte floppy disk. When I started using computers I would have liked a Unix based machine, but it required a massive 20 Mbytes for a full install: that was the size of the average harddisk on a PC, so no where for data. Now people are trying to get Linux installations down to 100 Mbytes: such as damn small linux or puppy linux. These still have graphical user interfaces: so what is all the stuff in Windows XP? Unix was once desirable because it was the main operating system for scientific and engineering software. Now most such software is written for MS Windows, that which is available for Linux is incomplete or typically cumbersome to use.

Windows XP doesn't even have to be released as open source. The source can be protected. The main requirement is that can modify the system and can distribute the modifications: and do not require the source code to do that.

The first variation that is likely to arise is reducing the system size, and making it modular. Delete everything that is unnecessary on a stand alone PC which is not networked and does not have internet connection. Rip the system back to launching a simple command prompt, and having no more capability than a old MS DOS bootable disk. Then have separate installers for adding extra capabilities. My current Windows 10 folder is about 34.8Gbytes . Now I don't know how much of that is unneeded remnants from Windows 7, or how much is due to low quality software dumping files in the Windows folder because the software developers haven't figured out the fundamentals of their software finding itself. It does however seem excessively large.

A personal computer should be simple enough that a user can explain the presence of every file and folder on that computer. If they do not know what it is, then they should be able to delete it. If not then the file doesn't belong their. The operating system may belong to Microsoft, however the computer belongs to the user. A company has no right to be modifying the contents of a personal computer, and certainly no right to be recording history in typically hidden folders. The history typically has no value to the user: it is not like they can retrieve the data and then invert every command issued to undo something that went wrong. I probably open about 100 or more files every day: the recent file list is of no use to me. Now whilst its display can be switched off, it doesn't stop the system recording and wasting hard disk space. How many people have bought new computers because they are unaware of how much junk the system and other software produces in the background?

As I recollect Windows XP was around 1 to 2 Gbytes, and I didn't and don't need all its capabilities. So what is all the stuff required by Windows 10? Its graphics have been deteriorated, so that not as clear where one element starts and another ends. Office 2016 seems unstable, with displays becoming split or distorted. Plus Office 2016 doesn't seem to like file association, it typically generates an error when attempting to open a file the first time. Loss of multiple document interface (MDI), single container for Excel is also a backwards step. It is more inconsistent now than when had MDI. With MDI can organise files inside Excel without messing desktop organisation of other applications. Whilst it may be possible to organise the Excel files separately than other applications, its necessary to remember that some of those Windows on the desktop belong to one application, and only want to arrange them, so don't arrange the desktop, arrange from within Excel. Even so there is still loss of control over the size of workbook Windows. Multiple workbook and multiple Window Excel applications become inconvenient. I'm not convinced that the UI/UX professionals really have any understanding of human behaviour.

Whilst LibreOffice is useful, its spreadsheet application is no where as convenient to use and automate as MS Excel 1997. However the primary requirement for a computer user is that files created yesterday can be read and edited tomorrow. Having standards for data exchange is important. Such standards should be flexible enough that content can be added or deleted without causing the readers and writers to crash.

The difference between AutoCAD and AutoCAD LT is that the LT version cannot create or edit certains features of a drawing: however it is able to either display those features or identify that they exist but cannot be displayed. The file can also be edited without loss of those features.The difference between AutoCAD and IntelliCAD is that AutoCAD commands typically execute faster and screen displays update correctly, thus providing proper feedback to  the user. So IntelliCAD maybe able to open the drawing files, and it maybe lower priced, but its operation is less user friendly. However, interacting with software tends to be wasteful compared to automating that software: and if objective is to remove or minimise human interaction, then the automation capabilities of IntelliCAD make it a suitable substitute for AutoCAD. However parametric CAD is still less time consuming and more flexible than automation and parameterizing via a general programming language.

Now whilst Microsoft and Autodesk both acquired a dominant position in their respective markets, they cannot maintain that dominance with their current product offerings. The population at large does not need nor want the current product offerings. It was important that Ford only offered black cars, so as to make cars affordable to the public at large. But now that the basic need has been essentially saturated in the industrialise west, cars need to be produced in smaller batch sizes to meet niche markets. Likewise mobile phones cannot be sustained on an assumption of a consumer market with regular updates of new models. Most of the capabilities of mobile phones are gimmicks: junk with no real long term value to the end users. However having put capability there, it is not acceptable to abandon such feature in future releases and leave some people stranded.

Whilst there may occasionally be issues associated with infrastructure and connectivity, the primary issue is loss of capability when modern technology is used in its stand alone isolated mode. A pocket calculator is still faster and more reliable than a mobile phone or desktop computer. However a computer has the potential to replace the 1000 or more books I own, and take up considerable less space. More over a computer can do this without need to be connected to the internet. The internet of things at this point in time is more gimmick than anything useful. Most likely fueled by TV shows and movies which show unrealistic capabilities of computers. Computers cannot break the laws of physics. Control requires more than simply connecting sensors, it requires electric motors attached to the equipment, and motors require a power supply. Rather than electronic sensors reducing maintenance costs of remote equipment, it is likely to increase the costs: as the robust mechanical equipment which only occasionally needed maintenance is now appended with fragile electronic junk. The internet and the web does not equate to technology.

[Case in point. Around 15:30 blogger has problems automatically saving work, but manual saving works for a time. Then saving hangs. I can copy the post to clipboard. But Notepad won't open, so cannot save. Task manager also doesn't open: not sure about the point of a task manager that is resource intensive and frequently fails to open. Switch power off, and reboot. Check power off settings: can shutdown and install updates or restart and install updates. Either way no choice about accepting updates. So basically can attribute the source of the hanging being updates hijacking web resources and other computing resources. So decide to restart with the updates: 17:42 computer reboots, I think its the final reboot, but no: its still only 75% way through. 18:11 get to log back on and it says "Hi". Are you kidding me! You effectively hijack my computer, to make changes I didn't ask for, and waste my time and consider you can be jovial about it. 18:20 can actually do something with the computer: with my computer.]

So if Windows XP and Office 2003 are considered too old to support then release them to the community to support. I'm reasonably certain that they will rip it back to the absolute minimum install. As for the internet it has very little to do with computing, so develop it without messing up the systems used for computing.

---

Related Posts

---

Revisions:
[02/10/2016] : Original

Metamorphs Product Ideas

Various Product Ideas had over the years. So yet another check list for determining what I have actually pursued and otherwise released.

---

ProjectID	Title
M001	Shed Design Charts
M002	Shed Design Manual
M003	PreFabricated Buildings Manual
M004	Kleinlogel Spreadsheets & Applications
M005	Utility Disk
M006	Easy Calculators
M007	Generic Details
M008	Component Design Tables
M009	Soil Heave & Geotechnical
M010	Online Engineering Services
M011	Stock Management
M012	Project Manager
M013	Conveyor Design - Mechanical Handling
M014	Pipe Profiler
M015	Wind Loading Calculators
M016	Beam Analysis & Design
M017	Carport Design: Prescriptive Solutions
M018	Plane Frame Analysis & Design
M019	Drawing Office & Document Manager
M020	Personnel Manager
M021	Program Writer
M022	Metamorph Calculator
M023	Program Converter
M024	File Manager
M025	Cosmos - engineering data management engine
M026	CADD Tools
M027	IE Toolbox
M028	Standard Forms
M029	Architectural Details & Floor Plans
M030	Multiframe Applications
M031	Library Manager
M032	Civil Engineering Scriptwriter for AutoCAD LT
M033	Preprocessor/Postprocessor for Lights
M034	Microstran Preprocessor/Postprocessor
M035	Canopy Design: Software for Custom Design
M036	Excel Application Model
M037	Experimental Frame Design (Shelter)
M038	ColdFormed Steel Design
M039	HotRolled Steel Design
M040	Timber Design
M041	Concrete Design
M042	Masonry Design
M043	Civil Engineering Toolbox
M044	Structural Engineering Toolbox
M045	Mechanical Engineering Toolbox
M046	Enterprise Ideas

My spreadsheets DAO and 64 bit Windows 7

In process of reluctantly moving over to Windows 7, found a problem with my spreadsheets. Didn't want to change operating systems, but faulty power adapter connection forced me to get a new computer, that was about 18 months ago. Thus far the 64 bit Windows 7 computer been a good dust collector, as little installs on it, and it is otherwise slower than a wet weekend. What's with the spinning cursor, just execute the command already, instead of unnecessarily animating stuff: supposed to be a general purpose personal computing device not video game. Software developers seem to have lost the plot about what a personal computer is, and difference with a micro-computer and the importance of stable infrastructure. Not to put too fine a point on it but a virus is an annoying irritating piece of software which interrupts the users use of their computer: eg. Microsoft updates are a virus. All computer seems to have done for past 18 months is download updates: switch on to move software licenses, cannot do anything because updates need installing, runs out of battery power needs recharging, go do something else. Get more spare time, repeat same process, during which process seems to have got infected or otherwise messed up. Internet explorer dead, camera not functioning, and cannot install software for. Seems like may have to wipe clean and re-install from scratch. And there's all this rubbish about XP being defunct: its working perfect. Any way write more about operating systems and personal computers later.

Since I don't have 64 bit office, not even current for that matter (why would it need to be, I customize my own stuff), it seems that the Microsoft DAO 3.6 object library gets placed elsewhere. Normally it would be:

C:\Program Files\Common Files\microsoft shared\DAO\dao360.dll

On 64 bits using 32 bit software its likely to be:

C:\Program Files (x86)\Common Files\microsoft shared\DAO\dao360.dll

So to use my technical library will need to manually change the reference in the vba editor under tools references.

When first started with computers I avoided Microsoft products and stuck with Borland (Turbo Pascal, Turbo C, Quattro Pro, Paradox). I cannot go back down that path, but considering the free software options which are available on both Windows and Linux platforms. Start with them on Windows get used to them, and then move over to Linux. Zorin OS may be something worth looking at. There are a lot of problems to move over to Linux, from major applications (AutoCAD, Multiframe) to small utilities (xyplorer, beyond compare). But back in the early 1990's most high end graphical engineering software required a unix workstation: and likely a specific workstation like a Sun sparc. The problem being drivers for graphics, mice, and printers. At DOS every software developer needed to write drivers for their own application, and similarly with unix/Sun OS locked  to specific or limited range of hardware. MS Windows eliminated part of the problem, if the computer could run Windows then chances are could run specialist software.

The problem we have now though is not about supplying to meet needs, but changing stuff to acquire future income. Need and demand been satisfied, so what can be done to generate income tomorrow. I know, lets knock all the bridges down, along with the power stations and water filtration and pumping stations. Got a new fangled super material and I reckon it would be unsafe, a major national security risk, to keep all these things made out off that rubbishy concrete stuff. Whilst we're at it lets rip up those copper wires and optical fibre rubbish: you know the ones that connect the internet. And those tarmac, asphalt and concrete pavements they're ugly so lets get rid off them to: I'm sure we can think of something to replace them with, might but half defective and inferior. Wheels yeah, lets re-invent them, triangular ones they'd look good: wouldn't work, but who cares its change, and shouldn't resist change. There is just so much garbage on the internet about upgrading, and resistance to change. You do not destroy the heritage, the infrastructure the foundations on which everything is built.

Windows 8 apparently would be faster than Windows 7, and possibly fix the speed issue I have, but its likely more incompatible with the software I want to run. All I needed was new hardware. Software is expensive and bought progressively over the years: but having got, its not so easy to put aside and replace progressively.

On the other hand I did have a personal policy that engineering stuff I'm supposed to be able to do with pencil and paper, we should develop software in-house for and not depend on commercial software. So CAD or graphical editor is really only obstacle to moving to different operating system: most anything else just requires a compiler or spreadsheet.

However, there is no point to changing operating systems or application software if it is automatically updating on a regular basis. Once installed I expect the software to remain unchanged unless I find a problem with it. As for the internet and security, it is not necessary to be connected to the internet all the time, or have every device connected to the Internet.

We still operate DOS boxes because some software no longer available, or if new Windows version is available there is no benefit which would justify the expense, and otherwise doesn't function at Windows command prompt. I don't believe that kind of updating should have occurred, after all MS DOS ran from a 720 kbytye 3.5" floppy disk, so it should have been possible to fully accommodate in the 1 o 2 Gbyte bloat of the current Windows operating systems. From memory Sun OS had a full MS DOS installation which opened in a separate process window.

So it shouldn't be a problem to have an operating system which spawns different operating environments in isolated containers visually indicated  by windows. I think exists already and its called Unix.

Wind Loading Surface Roughness Length versus Terrain Category

A simple spreadsheet making use of AS1170.2:1989 Appendix E. This appendix provided formula for converting surface roughness length (z0) into terrain category and for region A the calculation of the terrain adjusted wind speed or otherwise the terrain category multiplier (Mz,cat).

AS1170.2 commentary contains a design chart which identifies various terrains and gives the surface roughness length (z0). From this chart it is apparent that most rural properties are not TC3 but also they are not TC2. By the use of z0 an intermediate terrain category can be calculated and more economical designs are possible.

The spreadsheet can be downloaded here: surfaceRoughnessLength.xls

---

Revisions:
[07/04/2014] Original
[23/04/2016] Changed download links to MiScion Pty Ltd Web Store

Wind Loading Risk Assessment

A simple spreadsheet which allows varying life expectancy and calculates the mean return period (R) for the regional wind speed. It is based on formula in Wind Loading of Structures by John Holmes.

It also attempts to map the calculated mean return period to the nearest building code of Australia (BCA) importance level, and return the associated mean return period for such. This part is limited to non-cyclonic regions: A and B.

The file can be downloaded here: windRiskAssessment2014.xls

---

Revisions:
[07/04/2014] Original
[23/04/2016] Changed download links to MiScion Pty Ltd Web Store

Wind Loading BCA Importance Levels

A simple spreadsheet that maps Building Code of Australia (BCA) importance levels against the annual probabilities of exceedance (actually mean return periods). Excel trend line facilities are then used to get a formula so that any mean return period can be mapped to an importance level.

Whilst AS1170.2 allows for any mean return period, the BCA has limitations, which are not always suitable, starting with the fact that the BCA is primarily about habitable buildings and anything which is not a habitable building becomes BCA class 10. However the BCA is not suitable for design of any structure classified as class 10. For example a garden shed or carport may be suitable to be designed to BCA volume 2, but a 600m high radio mast is not.

Additionally importance level 2, with mean return period (R) of 500 years is not suitable for all buildings, and then again an importance level of 1 (R=100 years) is not always suitable, therefore helpful to identify alternative importance levels: to show that have importance between 1 and 2.  For those who prefer importance levels.

The spreadsheet can be downloaded here. bcaImportanceLevels.xls

---

Revisions:
[07/04/2014] Original
[23/04/2016] Changed download links to MiScion Pty Ltd Web Store

Revised Links to downloads

The links to applications and MS Excel workbooks which were stored on the personal web space which came with my Internet access account have now been replaced with links using Dropbox. So the downloads should be available again.

Plane Frame Analysis Front End Version 4

frontEndPFrame04.xls

Now converted the variables, used in the various plane frame analysis applications, from records to classes. This version of the front-end for cpframe.exe can read a data file into the variable, then store the contents of the variables to the worksheet. It can also read contents of the worksheet and store in the variables and then write the contents of the variables to a file.

In this way existing data files (.dat) can be opened and edited in Excel. Since reading a file into a workbook over writes the contents of the cells, its not a good idea to calculate the geometry or required loading in the worksheet cells, it is better to generate the model using vba which is the point of the exercise. Using the variables and data structures now defined can write vba code to build a model directly into those variables and by pass the worksheet. The worksheet was just used to verify can read and generate the file through the use of the variables. The file format of the output doesn't match the file read, as the original data files were generated by QPro. Once I had got QPro to generate data files which pframe could read, I didn't worry too much that the file didn't match the exact format of the files saved by pframe. When converted to Excel the format for numbers was taken from the format assigned to the Excel cells, this is no longer done, the format is now hard coded into the vba code. This was done because the file read macro first clears the cells, whilst this has been modified to only clear the contents, the macro can read data files larger than the maximum formatted data area (highlighted in yellow in worksheets) and therefore some format will need assigning to these extra records. The hard coded formats also closely match the original Pascal formats: not liking some of the original formats I have changed them with out affecting the ability of the original application to read the data (thus far).

From this point forward will need to move away from buttons in the worksheet. As far as I know, vba variables have a life as long as the execution of the macro. Thus when macro stops, the variables cease to be accessible, though the memory may not be cleared. This is the reason for storing the contents of the variables to the worksheet, and then reading back from the worksheet. Though I did read recently that global variables do retain values between vba calls: maybe. Before  including the subroutines for reading the data into the variables I did trial reading then writing without storing and retrieving from the worksheet first: the two buttons seemed to work. However I put that down to valid data still being in memory, and same chunk of memory being addressed when macro next macro run, in other circumstances the data may not be valid and may address different chunk of available memory. This is based on past experience with Excel 97, though at that time I admit not overly familiar with use of the Public keyword, so past failures to initialise variables via open workbook method may have been because of not having global variables: though that seems it would have complained about unknown variables and the initialisation wouldn't have worked. Not something I really want to test or rely on: so will assume that from one vba call to the next all variables are wiped. Besides, since making the test for this application, I have removed the global variables and made local to the main class.

So on the assumption that variables are wiped from one vba call to the next it is necessary to keep the vba code active, and to do that need to move buttons from worksheet to a vba form: and have the form retain control until all tasks complete. The alternative is to repeat large segments of initialisation code on each vba call. This latter approach was adopted for the wind loading functions contained in schTechLIB, each function calls subroutines which load arrays which are then searched for data: may have to revisit that and see if I can initialise once.

Another problem to be addressed is access to the variables external to the class in which they are defined. The variables are arrays and vba does not allow public arrays in the definition of a class. So whilst converting records into classes in Turbo Pascal and Delphi is relatively easy its cumbersome in vba. An alternative is to use collections in vba, these can be public, however these are highly likely to be incompatible with the analysis routines of plane frame. {Noting that idea is to incorporate plane frame in the code not shell out and pass data file to a console application. The console application is just a development tool, and not affected by any code I write for the front-end creating the model to be passed to the frame analysis. The first task is to auto-generate a valid structural model of a manufactured  structural product (MSP): not analyse it, that task comes later.}

If don't use collections then need to write property (Let, Get, Set) methods to access the individual elements of the arrays. At present only written one of the classes in Pascal, vb.net and vba, and use of collections keeps vba most similar to Pascal and vb.net.

So as to which is the better option I will work out as I attempt to gain access to the variables and define a structural model.

---

Structural Design
At the moment I assuming that structural design is split into three stages:

Stage1
Consists of creating the structural model:

1. Dimension and Geometry
2. Design Actions

Stage 2
Consists of Analysing the structure and determining the reactions and action-effects. The analysis used depends on the analysis used. The tools used for the analysis depends on the complexity of the analysis.

Stage 3
Consists of:

1. Component sizing
2. Connection Design
3. Footing Design

However the whole process is not all that simple, as connections and footings themselves have their own components and may require repeating stage 1 to stage 3, using different analysis methods suited to the details of the component considered. That is steps 2 and 3 of stage 3 can be removed and these components considered as requiring their own structural models. {eg. connections modelled in isolation along with applied forces, using finite element method}

So cpframe only covers stage 2 for structures which can be modelled as plane frames. The front-end for cpframe covers stage 1, and the back-end covers stage 3. There is plenty of software available for stage 2 and stage 3: though not much choice for software covering Australian materials codes. It is stage 1 however where the problem lies with respect to rapid design of manufactured structural products (MSP). For simple MSP's a few simple calculations in a a spreadsheet will suffice for all stages, for more complex structures some analysis engine is required for stage 2. If using an analysis engine then a structural model needs to be built from simple user input. For structural frameworks the form of the structural model is relatively similar, for example I only need to add a few extra fields, add WriteArc methods to all the classes to export the model to a MicroStran .arc file. These methods I already have in classes specifically written for writing MicroStran files. {Pity I think MicroStran even needs to import the arc file. Otherwise could launch that instead of cpframe.}

So given that the data structures required to represent a structural model are relatively similar I can create my own data structures and use to create models for export to what ever structural software I choose. Note not concerned with picking up the dimension and geometry from a CAD model and adding loads to it: the dimension and geometry are to be auto-generated from a few simple parameters and no other variations permitted. If want other variations then export a model for import into general purpose structural analysis software. An MSP has a defined structural form and a limited set of parameters: if the structural form changes then it is no longer the off-the-shelf MSP. I don't see the purpose of software to permit design at point-of-sale (PoS) but to constrain the options available so that the customer knows they have just defeated the entire point and purpose of going to a supplier of MSP's: and consequently some significant period of design and engineering is not required. On the other hand want to make more customisable options available at the PoS. So that eventually get auto-generation of basic options and then manually edit more custom options: with the allowable editing constrained. {NB: Some advanced level CAD systems for more than 20 years now, have been able to define dimensions by mathematical expressions. For example the span can be set to twice the height. Plus various nodes or points can be used as constraints and references. However that doesn't necessarily equate to being able to increase quantity of components, such as varying the number of portal frames with the length of the building. Also in the building industry they don't pay to much attention to assemblies and sub-assemblies: so the building rather than being a series of portal frames becomes a forest of columns with a collection of rafters. Thus 3D modelling can change the perception of the structure: getting away from the sub-assemblies which make it up.}

Any case the focus at the moment is auto-generation of the structural model, and ultimately being able to analyse that model using various tools to get comparative checks on structural adequacy, so that independent technical checking is viable. In the past and even now, independent checking is a problem, the manufacturers use propriety software generate and check compliance in a few minutes and the city councils engineer certifying the structure may require a week to check the design using general purpose tools: or otherwise simply reading through the reports produced.

So my view is to provide the tools to the certifiers and general designers first for use with general purpose structural analysis tools. This in turn increases the potential for MSP's in the first place, and with MSP's comes the manufacturers desire to limit what the sales team can sell to keep the production economical. So go from the flexible to more and more constraints.

---

Download frontEndPFrame04.xls .

DISCLAIMER :
Users of the software must accept this disclaimer of warranty :
The software is supplied as is. The author disclaims all warranties, expressed or implied, including without limitation, the warranties of merchantability and of fitness for any purpose. The author assumes no liability for damages, direct or consequential, which may result from the use of the software.

---

Revisions:
[13/02/2014] Original

[23/04/2016] Changed download links to MiScion Pty Ltd Web Store

Future Development of our Plane Frame Program

It is not the intention to write a stand alone frame analysis program. Software such as MicroStran and Multiframe serve that purpose reasonably well.

Similarly it is not the intention to write software supporting a building information model (BIM). Software such as ArchiCAD, Revit Structural, RAM Build, Tekla (XSteel/XEngineer), Master Series Master Portal serve that purpose.

None of this software however is suitable for manufacturers of structural products who do not employ engineers on staff. Employing an engineer on staff is not overly viable: one a shortage and second the problem of a graduate gaining appropriate experience and guidance to do the required job in such places. Also civil engineers are not overly suitable any case they don't have the repetitive manufacturing and product development knowledge. They typically design buildings one at a time for a specific purpose to comply with one set of regulations. Local regulations are irrelevant when designing a product, the product may have to meet regulations in multiple regions with minimum variation to zero variation in its form. On the other hand mechanical/manufacturing engineers lack the building structures knowledge. More importantly an engineer employed on the staff of these manufacturers is likely to get bogged down dealing with the day to day hassles of cleaning up the mess created by the sales people.

The sales people and their customers need to be enabled and empowered to make the right decisions to keep their company out of trouble and avoid hassles for the customer. I've trialled tables: they always want smaller increments to the tables and usually want to opt for the unconservative direction when making a choice. I've tried graphs: there are unusual and incorrect ways to read simple graphs. Also a single graph or table doesn't specify the requirements for a complex assembly, multiple such design aids have to be used and so complicating the process. Hence software is seen as the solution by the manufacturers and they typically seek an Excel spreadsheet. An Excel spreadsheet typically because they know of something similar used else where or because they know we and others use Excel for our calculations.

Spreadsheets with calculations directly in the worksheet are not however a sensible option. It can involve a considerable amount of work just to add one additional structural element. Using arrays or records such additional structural element can be done with relatively minor effort. Therefore using a programming language like vba/Pascal and a database like MS Access or sqlite is more efficient use of computing resources. Efficient use of computing resources potentially becoming important again as the use of smart phones increases, along with Internet services.

From such perspective Java and JavaScript may be considered the more preferable programming languages. As these are more readily available programming languages for the Internet and Android phones.

To convert either the vba or Pascal source to vb.net, I have to convert all arrays to zero based indices. Since Java is largely C like in its syntax I assume it also requires zero based arrays. Therefore could adopt Java in preference to vb.net, however Java is likely to impose more constraints on the use of classes. Further as with Lazarus, Java has the problem that it isn't immediately compatible with the .net framework: and writing either a COM automation server or .net component is going to be more complex than with Visual Studio and vb.net. Since I would like to produce something which can be used in either Excel, MS Access or referenced in some other application, COM or .net is important.

At present however it is easier for me to convert the Turbo Pascal source into using class/objects and to using zero based arrays. To do this in parallel with further development in Lazarus vb.net and vba. At the same time modify the program so that it is based on constructs which make it easier to translate to Java and C#. Where C# provides compatibility with the .net framework and Java with Android: with the two languages being about as similar as vb.net and vba.

The approach may be slow, but it will permit the modules of the intended larger application to remain functional in at least one programming environment at any point in time.

pframe needs a back-end for member design for steel, cold-formed steel, timber and aluminium members. Currently this is only available in vba. Connection design only available in Excel worksheet calculations.

Developing the back-end however I consider to be off secondary importance as such facility to a limited extent is already available in software like MicroStran and Multiframe.

The feature missing from most of the commercial software for the Australian market is auto-generation of the structural model. Sure the software can generate the dimension and geometry for a few common structural forms: but the software doesn't auto-generate the structural model with the loading. Nor is the software able to iterate through various structural models subject to some constraint: such as increase height until some maximum moment is reached. {Though Multiframe is a COM automation server and can be programmed for such task}

With respect to auto-generation of a structural model in the form of data files for pframe and MicroStran that is already written in Delphi and vba. Converting it to vb.net is expected to be relatively easy. However having auto-generation as an integral part of pframe would be a lot better, rather than interacting only via data files. Since converting pframe to vb.net is the obstacle, merging the Turbo Pascal and Delphi source seems the fastest approach: other than the wind loading is obsolete. The wind loading however really needs modifying so that it gets data from files rather than hardcoded arrays: for which purpose XML files maybe suitable.

History of the Development of our Plane Frame Analysis Application

The earliest dated Pascal source files I can find on our systems are dated 1990, however I didn't start using the program until the 1996 version. The 1996 version uses Turbo Gadgets to provide walking menus, and it otherwise uses the full graphics screen to display moment diagrams etc... This I wrote about in a previous post on my blog: since its a DOS based program using the full graphics screen its not overly compatible with windows: works Windows XP but not windows 7.

Back in 1996 the program was the only frame analysis program Roy Harrison & Associates (Now MiScion Pty Ltd) used. A few years later we purchased a MicroStran license, and a few years after that, rather than get a 2nd Microstran license we got a Multiframe license as a comparative check. Once we had the commercial software, this simple plane frame program fell out off use. {The application at this time had names alternating from f_wrk.exe to frame.exe}

Over the years however we have been repeatedly asked if we can supply software to help our clients sales personnel customise their structural products at point-of-sale (PoS). None however were really serious about investing in the development of such software: just an hopeful expectation that since we did everything by computer and we wrote the tools for such, that we could just throw something together. Not that simple.

The program as released here (cpframe), is the console(c) version of plane frame (pframe), I have removed the user interface. I never really used the user interface of the original program: this is because I wrote and used Borland Quattro Pro (QPro) macros to generate the data files. Our original projects involved standard calculations for sheds and carports, subject to a set of conditions but with a requirement to find the maximum height possible. Since wind loading is dependent on height, I needed to calculate new wind loads for each height until I found the limits of the structural section being used.

pframe.wb1

I could have wrote additional Pascal code and merged with pframe to achieve such objective, however already had QPro spreadsheets for general wind loading calculations, it was therefore faster to write QPro macros to generate the data files for pframe.

Similarly could have wrote more Pascal code to integrate coldformed steel design AS1538/AS4600 into pframe, but once again already had QPro spreadsheets for general design of members and connections. In terms of solving clients current problems had no time to develop a full application in Pascal.

AS1538.wb1

Now whilst QPro could launch pframe, pframe didn't support command line parameters. Therefore I had to manually open the data file and run the analysis, then import results in QPro. Since pframe only supports a single loadcase, I had to repeat this procedure for each loadcase. Pframe was thus a bottleneck in the whole process that I wanted to remove. {This bottleneck was slightly improved once we got MicroStran and I modified the QPro macros to generate microstran .arc files. Microstran could deal with all loadcases and envelope the extreme values, thus reducing the total number of steps compared to using pframe.}

Back in 1996 however I had an aversion to touching the Pascal source code for pframe written by my father and adding the desired command line parameters or otherwise expanding the program. The aversion stemming from not having any simple and rapid means of testing the program to ensure I hadn't messed up the calculations.

So I needed an alternative method. Whilst moment distribution is easy enough to learn for continuous beams, its an otherwise cumbersome approach for plane frames (though extremely practical when there isn't anything else). American texts tend to show moment distribution calculations littered about a diagram of the frame whilst others present a more tabular approach. Either approach seems messy, and prone to error. Since I had a steel designers manual with Kleinlogel formula for the frames I was most interested in, I adopted Kleinlogel formula.

Still using Kleinlogel formlua is time consuming and prone to error, so I set up a spreadsheet to do the calculations. Spreadsheets being slightly cumbersome however, I decided to also program the calculations in Delphi 3 (Pascal).

Qpro macros for AS1170.2 wind loading

Parallel to this was the desire to expand the wind loading calculations and make them more complete and not just limited to the few scenarios most often encountered and manually handling other scenarios. Since more familiar working with arrays in high level languages like Fortran, Pascal and C it seemed easier to develop the wind loading functions  in Delphi (Pascal) than in the QPro macro language. So wind loading calculations were thus developed in parallel in QPro and Delphi, one used as a check against the other.
Now the problem with QPro macros is that the calculations are not up to date unless the macros had been run, and these were either run when the dialogue boxes collecting data were closed or when an hot key was used. This made the spreadsheets slightly cumbersome, but I had read somewhere that there was potential to create a dynamic link library (DLL) and add functions to QPro and this seemed possible using Delphi. Though I had't read in detail how to do so, and it seemed complex anyway, the potential was there. Hence the parallel developments in Delphi and QPro were not considered wasteful as they were expected to merge at some point in the future.

However, whilst wandering around book stores during my lunch break whilst working on contract in the city, I bumped into a book on Programming Office 97 using Visual Basic for Applications (vba). I had read some articles in computer magazines about Excel/vba but wasn't sure how vba related to Excel, plus I had a bias towards Borland software. Still I bought the book.

I had been hoping that Borland would merge the IDE's for Turbo Pascal, Turbo C and Turbo Basic and ensure they had the same function libraries, had built in language converters, including converters to turn GWBASIC into simple QPro spreadsheets or Paradox applications, and further more would be the programming languages for Paradox and QPro. They kind of did this, they threw Paradox and QPro away and developed Delphi and C++ Builder. Corel QPro I didn't like it was buggy. However, it was our 2nd QPro for windows license, and time was being wasted modifying my Borland spreadsheets to work in the Corel version. I didn't want to solve that problem by getting an additional Corel license. I was looking for an alternative spreadsheet, after reading the book on vba and office 97, I went and bought Office 97 Professional and the systems developer kit (SDK).

The wind loading functions I had programmed in Delphi, I translated into vba, thus making them available as functions in the Excel worksheet. A simple change to a spreadsheet cell and all the wind calculations upto date and the frame analysis using Kleinlogel also completed. Manually changing parameters in the spreadsheet I could quickly map out the potential of all the available c-sections for use in cold-formed steel sheds.

But still had a problem. Translating the dialogue boxes from QPro to Excel 97 wasn't so easy. Connecting the dialogue boxes to cells in Excel seemed cumbersome compared to QPro, I may have been doing it wrong but I had no real references for such. I tried the QPro way and that didn't seem to work: a similar approach does work in Excel 2003. Though there is still an issue of being able to abandon the dialogue box and not automatically updating the worksheet: such was not a problem with QPro1. Besides it appearing cumbersome to allocate data to drop down lists on the dialogue boxes, there was another problem with Excel and that was timing. There seemed to be a timing problem between getting data from dialogue boxes, evaluating user defined functions (UDF) and updating worksheet calculations. Either crashing or simply not calculating the correct answers.

Initially I had tried to replicate the QPro like wind loading macro's making use of the worksheets to store the data tables, but that appeared to be part of the timing problem and therefore I decided to abandon that approach in favour of using arrays in vba. Due to the problems with dialogue boxes, I abandoned them in favour of setting up input forms fully in the worksheet. Once the scope and life times of vba variables were better understood the workbooks worked fine.

But due to the problems encountered with programming vba, development continued in parallel in Delphi. I did attempt to iteratively change the structure height in an Excel worksheet and capture the resultant maximum frame moment and tabulate them. But a clear timing problem in that situation: the height can be changed faster than the worksheet can update the calculations. Incorporating delays could have probably fixed it, but why incorporate delays when objective to get calculated information as quickly as possible. Hence the Delphi program was expanded to iterate through the heights, or through the spans or through both heights and spans and calculate a table of maximum moments.

I then decided to produce a height/span chart and charting in Excel seemed easier than using Delphi graphics. Using Excel I could produce and store tables and charts and any other reporting may want, further more I could control Excel from Delphi. Unfortunately the Excel type library didn't import properly into Delphi due to keyword conflicts. The consequence was that programming Excel from Delphi was being done blind. Bit of a problem as Delphi uses [] for arrays and () for function parameters whilst vba uses () for everything. So that part of the application also needed parallel developments in Excel and Delphi, test what I needed to do in Excel then translate to Delphi.

This however was interrupted by changes to the wind loading code (AS1170.2), and since developing the application was a side line to day to day structural design, it was more important to update the general purpose wind loading Excel workbooks rather than update wind loading in Delphi. As a consequence Delphi was abandoned for developing the height/span charts, and it was all written in Excel/vba, all calculations in vba and thus avoiding problems of timing with worksheet calculation up dates.

Since we had been going down the path of developing a stand alone application in Delphi, pframe was part converted to Delphi to create a windows application with the graphics for the moment diagrams added, but without the rest of the interface developed.

However due to all the member design (AS4600/AS4100/AS1720) all being written in Excel/vba only, and the wind loading up date issue, it was considered that move over to development in Visual Basic might be more productive. So we obtained Visual Studio (VS) 2003 and VB.net, and then to get a second license we ended up with VS 2005.

But spreadsheets are still easier to format reports in, than messing around programming Delphi or VB.net. Sure those who prefer MathCAD type presentations think otherwise: that Excel is poor for presentation. For some reason there was some resistance to pushing forward with Delphi or VB.net development because of resistance to plain ASCII text files (.txt) or rich text files (.rtf), and complications of print preview and getting things to printers. But none of that is really a problem with MS Windows as notepad(.txt) and wordpad(.rtf) are available on each machine. Sure there is a possibility that the user can modify the results: but they would have difficulty proving and replicating such contended error in the program. Further today results are typically sent to pdf files rather than paper print out: and the pdf files can be edited.

Which is another point we had started to trial, generating pdf files, and produce all electronic documents early in the 1990's, but it was cumbersome to use pdf files where we needed results for further calculations. It was far easier to use paper printouts and mark up the required data. Scanning handwritten calculations to incoporate with computer generated calculations also produced massive pdf files, and so electronic documents were abandoned, we didn't have large enough hard disks to store the stuff, and zip disks were expensive. Hence further reason to integrate all the calculations electronically: eliminate the paper print outs for reference and produce smaller pdf files.

VB.net turned out to be significantly different from vba, and therefore it was put aside and pframe was converted to Excel/vba (xlFrame), so that it could interact more directly with Excel worksheet for input data and reporting.

Not long after doing that we were approached to provide a structures module for a carport/verandah spreadsheet. Whilst the structures module is relatively small the spreadsheet itself is relatively large, much of it is data and could probably be better done using MS Access: which is another development track pursued along with Paradox with respect to the materials management.

Now the Delphi application besides using Kleinlogel formula to generate height/span moment tables, it also generates data files for pframe, MicroStran (.arc) as well as AutoCAD LT scripts (.scr), it can also read data files from various other programs written. Much of this has been converted over to Excel/vba and extended further but as separate Excel workbooks. Attempting to gather a lot more vba code together into a single integrated applicataion hit some limit of Excel/vba. Whilst the code seems to run ok, its not possible to work on the modules as attempt to close/save the file it hits a memory limit and basically crashes. It won't save the file except through its recovery feature with all the vba code removed.

Since I don't consider I should use a better computer with more memory, nor that I should reduce the number of vba modules, further development in vba has stalled. Leading me to revisit VB.net.

The expectation was that could simply change the xlFrame into a COM automation object or .net component or similar, which can be plugged into Excel. Then all the parallel developments would disappear as all my wind loading and member design function libraries and the plane frame analysis could all be in vb.net and possibly a single library. Unfortunately that prior problem of the differences between vb.net and vba makes such conversion difficult for the plane frame analysis: though a simple conversion for the function libraries.

Also I want software like the carport/verandah software to export data files compatible with pframe and also to generate MicroStran arc files. When testing the data files exported by xlFrame they were not compatible with the 1996 version of pframe. This led me back to looking for Turbo Pascal source code to compile the original 1996 version of the program, and trace why the new data files were not compatible. Finding source code which compiled and used the same data files as the operational exe file, and which also produced correct results wasn't so easy.

The change in the file format was attributed to a change in how partial loads were defined. The error in the calculations was tracked down to dynamically allocated variables being freed from memory before results stored in those variables was actually used.

So having gone back to Turbo Pascal and given I prefer object pascal compared to vba, especially with respect to arrays in classes, it does seem that further development in Pascal may be the better option than vb.net, with Lazarus being a viable alternative to Delphi. Though a COM automation server may not be so easy to develop in Lazarus as it is in Visual Studio.

Anycase at the moment maintaining parallel developments in Turbo Pascal, Delphi 3, Lazarus, vb.net (VS 2005) and vba as I convert the record data structures into class/objects. The main difference at the moment is that an array has been converted into a collection in vba, though I may convert that back into an array and write property functions to access it. Both these vba approaches seem cumbersome compared to the other languages.