Icetips Blog

Last Monday, Ed Robinson CEO of Aptimize (http://www.aptimize.com) talked at our .NET user group meeting in Redmond, about optimizing web sites. He pointed out one of the tools they use, http://www.webpagetest.org It is very interesting to run this on your site to see how it will perform.

It lists every item that is downloaded, every file, how long it takes to download, how long the server response is etc. It gives you a really good idea how long a website takes to load from various parts of the world as they route the signal through various servers, for example in the United States, Britain, the Netherlands, New Zealand etc. Four things that Ed suggested to make pages faster to load:

1. Minify css and javascript files and anything else that can be minified. This can drastically reduce the size of those files as it cuts out all whitespace and with js files it also reduces the length of parameters and variable names.
2. Use sprites for images. This means fewer downloads, fewer roundtrip requests.
3. Consolidate files that are sent to the browser, such as css and javascript. This also reduces the number of requests to the server.

4. Compress anything that can be compressed. Here is an article about compression using php or .htaccess Here is an article on how to set compression on the Apache webserver.

I found an excellent writeup of website optimization that explains each of those items in more detail. Ed's talk was only 15 minutes, but by itself, was worth the 7 hour total time for the trip (including waiting an hour for the ferry after missing the last one by 2 minutes

We are in the process of slightly redesigning the Icetips website and the plan is to have it up by the end of June 2010 and we will definitely be looking into how to optimize it as much as we can. We all like fast websites and none of us like waiting for a web page to load! It will be an interesting experiment and I hope you will see a much quicker website by the time we are done with it

Arnor Baldvinsson

Today we have discovered a problem in the latest Clarion 7.1 build 6849. This problem affects most of our products and will cause a GPF in the program at runtime. What I found out was that the #PDEFINE template statement, which we have used for years to add defines to the project, doesn't fire in this Clarion 7.1 build so classes that depend on their own defines in the MODULE and DLL attributes are not compiled correctly and will cause a GPF when the classes are instantiated.

I have reported this to SoftVelocity's Problem Tracker and I really hope that this will be fixed in the next build.

If you converted projects from Clarion 6 to 7.1 with our products in them, you should be just fine. This only affects templates that you have added to applications in this latest build of 7.1 and possible some of the latest builds as I'm not 100% certain when this stopped working.

I am also looking into an obscure problem in the SQL browse template that only shows up in 7.1, when the GreenBar is being used and only when a new column has been added. After then app has been closed and re-opened the problem goes away and also if the actions for the SQL browse have been entered after a new column has been added. It could be something in our templates or it could be something that is related to the #PDEFINE issue if some statements are not executing correctly.

Arnor Baldvinsson

My client reported a problem when attempting to run our project that was a bit baffling:

"The procedure entry point _18ProtectedHashTable__ct__@FiP15CriticalSection could not be located in the dynamic link library c60runx.dll"

Since all that we are sending back and forth are the applications and no binary files there was no way that we were mixing any binaries up, besides we are using the exact same builds of Clarion 6.3 - 9059 so this shouldn't be a problem at all.

After asking around I found out that the reason for this is that Clarion 7 includes a Clarion 6 compiled version of Topscan, which is not compiled local so they have to distribute the Clarion 6 versions of the DLLs with Clarion 7. In our case, the Clarion 7 Bin path has been added to the PATH variable, either manually or by an installer (we do not know which one if it has been done by an installer). Not just that, it has been added in front of the Clarion6\bin folder in the path causing the Clarion 6 application to pick up the C60RUNX.DLL from the Clarion 7\Bin folder rather than the Clarion6\Bin folder.

After some experimenting, I found that at least for Clarion 6.3 build 9059 I could have both BIN folders in the PATH as long as the Clarion 7 one was after the Clarion 6 one. The Clarion 6 apps still run without problems and the Clarion 7 Topscan also runs correctly and without problems as far as I can tell.

So, IF you want to put the Clarion 7 BIN folder into the path statement, make sure that you do that after the Clarion 6 BIN folder. Normally you do not need to do this, but if you don't want to copy DLLs to the application folder using the PATH do access the binary files is one way to do it.

Update: It appears that if you are using Clarion 6.3 build 9056 it does not conflict with the C60RUNX.DLL file in Clarion 7.

Arnor Baldvinsson

I was doing some php research yesterday and stumbled on this online php book that had some very good information and examples that I could put to use right away. Check it out at http://www.tuxradar.com/practicalphp It's all online in html format, so there is no PDF etc. but it is easy to navigate with links to previous and next chapter as well as a "Jump to" drop down and a link to the table of contents.

The book has been updated for php 5.2 so it is kept fairly current, which is always a plus with online content!

So, if you are looking for good, free, text on php stuff, check this book out - it doesn't cost you anything

Arnor Baldvinsson

Currently there is no direct way to set a fixed filename for any of the output targets inside the Icetips Previewer, but you can easily do this on the report itself, rather than passing the name to the previewer and do it there. In fact this would probably be the preferred method since the report probably should determine the name and location of the resulting filename.

You need to put code into a single embed where you set the filename:

All the code that you need is just a call to the SELF.SetFileName() method. Please note that each output target has it's own Setup method so if you have multiple output target templates active you will need to do this for all of them. You can pass the filename as a string, variable or an empty string if you want it to open the file dialog in the Previewer when you print to PDF.

In this case you can use:

SELF.SetFileName('')  

This triggers the FileDialog to open in Previewer when you click on the PDF button.

SELF.SetFileName('myfile.pdf')

This writes the PDF file as "myfile.pdf" to the current folder.

SELF.SetFileName('C:\temp\myfile.pdf')

This writes the PDF file to specific folder, which is probably not what you want to do!

SELF.SetFileName(LOC:PDFFileName)

In this case a variable is used. You can prime the variable anywhere before the PDFReporter.SetUp method is called, or you can do it right before the SELF.SetFileName. Note that the PDFREporter.Setup method is not actually called until the report is in the Previewer so if you use a Global, Threaded variable, you can set this in the Previewer. Since the previewer and the report will always be on the same thread, you can just set this variable to be threaded and then there are not threading issues to deal with.

Here is an example of how this can be implemented. On the report I have changed the code to:

SELF.SetFileName(Glo:PDFFileName)

The global variable is a CString(2049) global variable with the "THREAD" attribute. To do that simply check the "THREAD" checkbox on the "Attributes" tab when you create the global variable - doesn't make a difference if you do it in the Global Data or in the Dictionary.

In the Previewer, all that is needed now is to set the global variable. Normally I would think that you would want to set the filename on the report, but this gives you an idea how to do it on the Previewer also. I have added an instance of our ITShellClass from the Icetips Utilities to the previewer procedure - in the "Local Data" embed I added:

ITS  ITShellClass

Now in the "Local Objects | Icetips Previewer | Clarion 6 Save Buttons | Before Save Dialog"

I have added this code:

  If GQ.GName = 'PDF'
    Glo:PDFFileName = ITS.GetSpecialFolder(IT_CSIDL_PERSONAL) &|
                      '\MyPDF.pdf'  
    !! Glo:PDFFileName must be be used in the report's 
    !! PDFREporter.Setup.

    If Not FileDialog('Select PDF to save',|
          Glo:PDFFileName,|
          '*.pdf|*.pdf',|
          FILE:SAVE+FILE:KEEPDIR+FILE:LONGNAME+FILE:ADDEXTENSION)
      Message('No PDF File selected, aborting PDF save',|
              'PDF Saving aborted',ICON:Hand)
      Exit
    End
  End

Note the "GQ.GName = 'PDF'". This allows you to just do the PDF if you want the default filename handling for other options. The GQ contains all the target names, such as "PDF", "HTML" etc. At the top of the routine that handles the targets in the Previewer, the correct item is selected from the GQ queue so throughout the routine you can use GQ.GName to determine what is the active target being printed to.

If you find new ways to use this, I would certainly appreciate if you would be kind enough to add a comment to this article so I and others can benefit:)

Arnor Baldvinsson