This site works best in a real browser - Code Snippets

Calling Maven2 from Ant

nospam@example.com (Graham Cox) — Tue, 17 Aug 2010 11:10:26 +0100

There is a lot of information available on how to call Ant from Maven2 scripts, but very little on the reverse operation. As it happens, this is actually quite simple to manage - Maven2 is a Java app, so it can be executed by simply using the Java task from inside your Ant script with the correct classpath, Main class name and arguments. The following snippit will do this for the simple case:

CODE:

Note that this depends on the property "maven.home" being set correctly, and when called it will require the "maven.target" parameter to be supplied. "maven.home" will likely be set in build.properties or similar, and calling it is as simple as

CODE:

CMake code to support asciidoc

nospam@example.com (Graham Cox) — Fri, 07 Nov 2008 13:14:38 +0000

Asciidoc is a really useful and sensible way of allowing people to write documentation, in that the plain text source code is nearly as readable as the generated output. The following is a CMake file to allow for conversion of text input files into asciidoc generated output files



PROJECT(Document)

FIND_PACKAGE(Asciidoc)

IF(ASCIIDOC_FOUND)

  FILE(GLOB _docfiles *.txt)



  FOREACH(_file ${_docfiles})

    GET_FILENAME_COMPONENT(_file_we ${_file} NAME_WE)

    SET(_in "${_file_we}")

    SET(_out "${_file_we}.html")

    IF (NOT "${_in}" STREQUAL "CMakeLists")

        ADD_CUSTOM_COMMAND(

            OUTPUT    "${_out}"

            COMMAND   ${ASCIIDOC_EXECUTABLE} -a toc -o ${_out} ${_file}

            DEPENDS   ${_file}

            COMMENT   "Asciidoc ${_in}"

        )

        ADD_CUSTOM_TARGET(${_in} ALL echo

          DEPENDS   "${_out}"

        )

    ENDIF (NOT "${_in}" STREQUAL "CMakeLists")



  ENDFOREACH(_file)

ENDIF(ASCIIDOC_FOUND)

And it needs the following FindAsciidoc.cmake file available



# - Find Asciidoc

# this module looks for asciidoc

#

#  ASCIIDOC_EXECUTABLE - the full path to asciidoc

#  ASCIIDOC_FOUND      - If false, don't attempt to use asciidoc.



FIND_PROGRAM(ASCIIDOC_EXECUTABLE

  asciidoc

  )



MARK_AS_ADVANCED(

  ASCIIDOC_EXECUTABLE

  )



IF (NOT ASCIIDOC_EXECUTABLE)

  SET(ASCIIDOC_FOUND "NO")

ELSE (NOT ASCIIDOC_EXECUTABLE)

  SET(ASCIIDOC_FOUND "YES")

ENDIF (NOT ASCIIDOC_EXECUTABLE)





IF (NOT ASCIIDOC_FOUND AND Asciidoc_FIND_REQUIRED)

   MESSAGE(FATAL_ERROR "Could not find asciidoc")

ENDIF (NOT ASCIIDOC_FOUND AND Asciidoc_FIND_REQUIRED)

Caret Position in a text control

nospam@example.com (Graham Cox) — Fri, 21 Jul 2006 10:23:52 +0100

Once again, IE proves that it can't do anything in a standard way.

Retrieving the caret position from a text control in Firefox and Opera is a very simple job - you simply use the selectionStart and selectionEnd parameters of the control itself.

Retrieving the caret position from a text control in IE is not quite so simple. There are no parameters that give you this information, so you have to work it out for yourself. As it happens, there are a number of ways of doing this available on the internet. Unfortunatly, none of them work properly.

The "official" method of doing it according to the Microsoft Web Team in the article Yule Not Want to Miss this One (See "O Cursor, Where Art Thou—finding yourself in a text box") is just horrible:

Save the input field value in a temporary variable.
Create a TextRange object on the document.selection (assuming the input field is focused).
Insert a “~” character into that TextRange object (range.text = "~"). Thus, the tilde would be inserted at the caret position (which we actually want to determine).
Search for the “~” character in the input field value and remember the index where it was found.
Restore the original input field value, saved at (1).
Return the index determined at (4) and claim it is the caret position.

The better method of doing it uses undocumented features of the Range object, and is described here by Mishoo.

This uses the Range.getBookmark() function which returns a value that can be used to get to the caret position. It worked fine. And in IE7 it stopped working. Microsoft changed the way this function worked (It's undocumented and so they can do that) and broke things that rely on it.

The third method of working out the caret position, which I have not seen mentioned anywhere on the internet and so might very well not work properly, is to use the Range.offsetLeft value. This gives you a value which represents the distance from the start of the text field that the caret is located at. In standard mode, this value is (position * 7) + 1.

This has been tested in IE5, IE5.5, IE6 and IE7 and returns the same values across all of them. It also returns the same value regardless of the zoom of the page and the location of the textbox on the screen.

As such, below is my cross-browser function to get the caret position from a given text field. It is known to work in Firefox, Opera, Netscape and (now) all versions of IE from 5.5 and up.
Continue reading "Caret Position in a text control"

Cross-Browser event object

nospam@example.com (Graham Cox) — Mon, 17 Jul 2006 17:34:54 +0100

Different browsers handle events in different ways. Unfortunatly, this means that the same function will receive it's data in different ways on different browsers. From the major three:

Firefox. Event object is passed as parameter to the callback function
Opera. Event object is passed as a parameter to the callback function. Some members of event object have different names
Internet Explorer. No parameters passed to callback function. Event object exists as a global variable(!) instead. Some members of event object have different names.

Whilst Internet Explorer does use a global variable to store the event object, this is actually less of a problem since the javascript engine is single-threaded. It shouldn't be possible to have two event handlers for two different events using the same event object. This could change in IE7 or later however, at which time things will likely all stop working in a horrible manner.

This snippit can be called, being passed the event parameter from the event handler, and will return an event object in a standardised way. Note that this is nowhere near finished, and still has a lot of work needed to cover everything. In specific, keyboard handling is very rudimentary (see below) and mouse handling is non-existant.
Continue reading "Cross-Browser event object"

Cross-Browser getElement()

nospam@example.com (Graham Cox) — Mon, 17 Jul 2006 13:42:55 +0100

This code is a simple Javascript function that works in most modern browsers to return a document element given the name of the element. It requires that both the name and id attribute of the control be set to the same value, and this value is what is used to look up the element.
Continue reading "Cross-Browser getElement()"