US prison contractor website is hacked

US website "Prison Contractor" is hacked. It is declared in  an anti-police campaign that anonymous hacker group have done this thing. One sub group "Antisec" took the responsibility of replacing the GEO GROUP website home page with a rap song dedicated to the murderer Mumia Abu Jamal.Mumia Abu is a former radio journalist serving a life sentence for the 1981 shooting death of a police officer.Hacker group left a message on a website home page that as part of our ongoing efforts to dismantle the prison industrial complex, we attacked one of the largest private prison corporations in the US - Geo Group.The hackers claimed to have gotten the addresses of more than 1,000 officers along with information from police warrants and court summonses as well as about informants in their weeks-long series of attacks on police computers. 

Read More

SQL query extension

By default, the standard program reads the entire main table when retrieving data for a particular form, even though some records and fields may not be required. By default also, the standard program reads only those reference table fields that are included on the form, even though the UI script and/or the DAL script may require other reference table fields. 

Query extensions define conditions that the standard program adds to the SELECT, FROM, and WHERE clauses of a database query in order to filter out unwanted records and fields of the main table and in order to include in the query all reference fields required by the form, UI script, and DAL script.

In the UI script, you program query extensions to minimize the number of records and fields of the main table read by the query and to retrieve any reference tables field that are required by the UI script but are not on the form. In the DAL script, you program query extensions to retrieve reference table fields that are required by the DAL script. 

When the standard program executes a database query, it automatically adds the query extensions defined in UI and DAL scripts. So, in the case of main table fields, the standard program reads only those fields and records that meet the conditions set in the query extension in the UI script. In the case of reference tables, the standard program reads those fields included on the main table and also those mentioned in the UI and DAL scripts.

Related Post:

• BAAN SQL

Read More

4GL Main table section

You use main table i/o sections to program actions that you want to be executed when read or write actions occur on the main table. These sections are not relevant to type 4 programs, as such programs do not have a main table. Main table i/o sections consist of a main section and a subsection. The main section is always main.table.io. The subsection indicates when the actions must be executed. 


Note that main.table.io sections (except the read.view subsection) are ignored when the corresponding DAL hooks are programmed in a DAL script.


Main section
main.table.io:
The subsections associated with this main section are executed either before or after input to or output from the main table. The main table for the current session is defined in the data dictionary. 


Subsections
before.read:
The actions programmed in this subsection are executed immediately before each read action on the main table.


after.read:
The actions programmed in this subsection are executed after each read action on the main table. You can use this subsection to call skip.io() in order to skip the record just read and to read the next record (if necessary). 


before.write:
The actions programmed in this subsection are executed before each write action on the main table. A write action occurs when a record is inserted. You can use this subsection to call skip.io() in order to undo the write action. 


after.write:
The actions programmed in this subsection are executed after each write action on the main table. A write action occurs when a record is inserted. You can use this subsection, for example, to write data to tables other than the main table. 


after.skip.write:
The actions programmed in this subsection are executed if a write action on the main table has been skipped as a result of actions programmed in the before.write subsection. The actions are executed immediately after the skip action. 


before.rewrite:
The actions programmed in this subsection are executed immediately before each rewrite of a record in the main table. A rewrite action occurs when a record is changed. You can use this subsection to call skip.io() in order to skip the rewrite action. 


after.rewrite:
The actions programmed in this subsection are executed after each rewrite action on the main table. A rewrite action occurs when a record is changed. 


after.skip.rewrite:
The actions programmed in this subsection are executed if a rewrite action on the main table has been skipped as a result of actions programmed in the before.rewrite subsection. The actions are executed immediately after the skip action. 


before.delete:
The actions programmed in this subsection are executed immediately before each delete action on the main table. You can use this section to call skip.io() in order to skip the delete action. 


after.delete:
The actions programmed in this subsection are executed immediately after each delete action on the main table. You can use this subsection, for example, for deleting references, if this is not done automatically. 


after.skip.delete:
The actions programmed in this subsection are executed if a delete action on the main table has been skipped as a result of actions programmed in the before.delete subsection. The actions are executed immediately after the skip action. 


read.view:
The actions programmed in this subsection are executed immediately after a view action on the main table (start.set, first.view, next.view, prev.view or last.view). You can use this subsection to call skip.io() in order to skip an entire set of records with the same value in the view fields.


Example
main.table.io:
before.delete:
if (not pctst099.del) then
skip.io("pctsts0001")
| cannot be deleted
endif
read.view:
if strip$(pctst099.cprj) = "" then
skip.io("")


endif


Related Post:

• 4GL Event Section

Read More

4GL zoom.from Section

You use zoom.from sections to program actions that you want to be executed when the current session is activated as a zoom process. A zoom process can be activated by a form-specific command of type session, by zooming on an input field, by pressing CTRL+B, or by calling zoom.to$() in the program script. Zoom.from sections consist of a main section and a subsection. The main section specifies the process for which the actions must be executed. The subsections specify when the actions must be executed.


Main sections
zoom.from.<zoom name>:
Each field has a name that can be used as a zoom name. You can specify the zoom name in this main section. The zoom name indicates which field the current session was zoomed from (when the subprocess is started from a form command, the zoom name is "choice"). The subsections associated with this main section are executed when the current process was zoomed to from the specified process. 


zoom.from.all:
The subsections associated with this main section are executed for all processes from which the current session can be zoomed to. 


zoom.from.other:
A subsection associated with this section is executed for all processes for which the particular subsection has not been programmed in a zoom.from.<zoom name> section.


Subsections
on.entry:
The actions programmed in this subsection are executed each time the current process is started from the specified process(es). You can use this subsection to import variables. 


on.exit:
The actions programmed in this subsection are executed at the end of the current process, if the current process was started from the process(es) specified in the main section. You can use this subsection to export variables.


Example:
zoom.from.all:
on.entry:
import("globvar", localvar)
on.exit:
export("globvar", localvar)


Related Post:

• 4GL Event Section

Read More

4GL Field Section

You use field sections to program actions that you want to be executed for a variety of field events. Field sections consist of a main section and a subsection. The main section specifies the field(s) for which the actions must be executed. The subsections specify when the actions must be executed.


Main sections
field.<field name>:
The subsections associated with this main section are executed for the specified field. The field name you specify must correspond with the name on the form. 


field.all:
The subsections associated with this main section are executed for all fields on the form


field.other:
A subsection associated with this section is executed for all fields for which the particular subsection has not been programmed in a field.<field name> section.


Subsections
init.field:
The actions programmed in this subsection are executed the first time that the form on which the field occurs becomes current. The subsection is executed immediately before the init.form section of the form. You can use this section to change field attributes.


before.field:
The actions programmed in this subsection are executed each time the focus moves to the specified field. The subsection is executed immediately before the before.input or before.display subsections. 


before.input:
The actions programmed in this subsection are executed immediately before input to an input field commences. This section is supported for backward compatibility only. In BaanERP programs, use enable.fields() and disable.fields() to enable and disable fields.


before.display:
The actions programmed in this subsection are executed each time that the specified field is displayed. You can use this subsection, for example, to set the value of a display field or to change the output format of currencies and dates (by using attr.oformat$). 


before.zoom:
When a zoom process is started on the specified field, the actions programmed in this subsection are executed immediately before the zoom process is executed. You can use this subsection to change the zoom attributes. For example, in the field definition in the form manager, a default zoom code can be specified. You can then use this subsection to change the zoom code (by setting the predefined variable attr.zoomcode). 


before.checks:
The actions programmed in this subsection are executed after input to the field has been completed and the TAB key has been pressed. The subsection is executed immediately before the domain and references are checked. You can use this section, for example, to change the value of the field before the domain and reference checks.


domain.error:
The actions programmed in this subsection are executed if the domain check causes an error after data has been entered in the field. You can use this section to provide your own error message instead of the standard message. 


ref.input:
The actions programmed in this subsection are executed if a reference error occurs. If you program this section, the standard program does not display a message. 


ref.display:
The actions programmed in this subsection are executed if there is an error in the reference display.


check.input:
The actions programmed in this subsection are executed immediately after the domain and reference checks. You can use this section to test for errors that are not detected automatically. If the standard program detects an error, input is automatically restarted. In a script, you can use set.input.error() to display an error message and start input again. 
This section is replaced by DAL functionality (if a DAL exists for the table).


on.input:
The actions programmed in this subsection are executed immediately after the check.input subsection. You can use this section, for example, to perform some appropriate action when the user enters a special character or to display a warning message in certain cases.


when.field.changes:
The actions programmed in this subsection are executed when the new value entered in the specified field differs from the old value.


after.zoom:
The actions programmed in this subsection are executed when the zoom process on a specified field ends. You can use this subsection, for example, to redisplay any field that has changed as a result of the zoom process.


after.input:
The actions programmed in this subsection are executed after all checks have been performed on input to the specified field and after the when.field.changes subsection has been executed. In this subsection, you can use the to.field() function if the sequence deviates from the default.


after.display:
The actions programmed in this subsection are executed just after display of the specified field. You can use this subsection, for example, to read reference tables.


after.field:
This is the last subsection for a field. The actions programmed in this subsection are executed after input to or display of the specified field. This section is always executed, even if the user left the field by pressing ESC, one of the arrow keys, or a mouse button. You can use this subsection to perform special actions before leaving the field.


Example
field.pctst099.item:
check.input:
select pctst001.*
from pctst001
where pctst001.item = :pctst099.item
as set with 1 rows
selectdo
....
selectempty
pctst001.dsca = "*****"
set.input.error(".....")
endselect
before.input:
if ..... then
attr.input = false
endif
after.display:
select pctst001.*
from pctst001
where pctst001.item = :pctst099.item
as set with 1 rows
selectempty


pctst001.dsca = "*****"
endselect


field.pctst099.date:
before.input:
attr.oformat$ = "%D002,2"

Related Post:

• 4GL Event Section

Read More

4GL Choice Section

You use choice sections to program actions that you want to be executed when standard commands are activated or ended. Choice sections consist of a main section and a subsection. The main section specifies the standard command for which the actions must be executed. The subsections specify when the actions must be executed.


Main section
choice.<standard command>:
The subsections associated with this main section are executed for the specified standard command. You use the Maintain Forms by Package VRC session to select the standard commands (ttadv3100m000) for each form. A list of standard commands appears at the end of this help topic.


Subsections
before.choice:
The actions programmed in this subsection are executed immediately before the specified command is executed. You can use this subsection, for example, to test data before the command process continues. You can use the choice.again() function to stop the command.


on.choice:
The actions programmed in this subsection are executed when the specified command is activated. These actions are executed instead of the standard action associated with the command. This subsection is available for the following commands only:

• print.data
• run.job
• global.delete
• global.copy
• bms
• all commands in type 4 programs (except modify.set, restart.input, end.program, abort.
• program)

after.choice:
The actions programmed in this subsection are executed immediately after the specified command has been executed. This subsection is not available for the end.program and abort.program commands.


 Example
choice.first.view:
after.choice:
execute(first.set)


Related Post:

• 4GL Event Section

Read More

4GL Group Section

With dynamic forms, the mapping of groups to forms is not fixed. Consequently, the only form section that is relevant to dynamic forms is the form.all section. When dealing with dynamic forms, you use group sections instead of form sections


You use group sections to program actions that you want to be executed when particular groups are activated or ended. Group sections consist of a main section and a subsection. The main section specifies the particular group(s) for which the actions are to be executed. The subsections specify when the actions must be executed – for example, when the group is activated or when the group is ended.
Note: that a group becomes active when the form on which it occurs becomes current. 


Main section
group.<group number>:
This section defines the group for which the actions programmed in the group subsections are executed. The group number is automatically generated when the group is created. 


Subsections
init.group:
The actions programmed in this subsection are executed only the first time the group becomes active, immediately before the before.group subsection. You use this subsection to program the first action to be performed by the system when the group becomes active. When the group is split across two or more forms (because not all the group fits on one form or because it is a repeating group), this subsection is executed the first time that the first form on which the group occurs becomes current. 


Note: the init.group section for group.1 is the former init.form section for form.1. Group number 1 is not one of the groups in the form-definition.


before.group:
The actions programmed in this subsection are executed each time the specified group becomes active. When the group is split across more than one form, this subsection is executed whenever any form on which it occurs becomes current.


after.group:
The actions programmed in this subsection are executed each time the form on which the group occurs is ended. When the group is split across more than one form, this section is executed whenever any form on which the group occurs is ended.


Related Post:

• 4GL Event Section

Read More

4GL Form Section

You use form sections to program actions that you want to be executed when forms are activated or ended. Form sections consist of a main section and a subsection. The main section specifies the particular form(s) for which the actions are to be executed. The subsections specify when the actions must be executed – for example, when the form is activated or when the form is ended.


Main sections
form.<form number>:
The subsections associated with this section are executed for the specified form. The <form number> is the sequence number of the form, as defined in the Maintain Sessions by Package VRC session (ttadv2100m000).


form.all:
The subsections associated with this section are executed for all forms of the session.


form.other:
A subsection associated with this section is executed for all forms for which the particular subsection has not been programmed in a form.<form number> section.


Subsections
init.form:
The actions programmed in this subsection are executed the first time the specified form becomes current, immediately before the subsection before.form. You use this subsection to program the first action to be performed by the system – a first.set or first.view, for example.


before.form:
The actions programmed in this subsection are executed each time the specified form becomes current.


after.form:
The actions programmed in this subsection are executed each time the specified form is ended.


Example:
form.1:
init.form:
execute(first.set)
form.other:
init.form:
display("disp3")
form.all:
before.form:


display("disp")


Note:
Only the form.all section is relevant to dynamic forms. For dynamic forms, use the group sections instead.


Related Post:

• 4GL Event Section

Read More

4GL Program Section

You use program sections to define functions, and to declare tables and global variables, that you want to use in the other sections in the script. You also use program sections to program actions that you want to be executed when the session starts or ends. 
The following program sections are available. They are all main sections. There are no subsections associated with program sections.


Main sections
declaration:
Use this section to declare tables and global variables that you want to use in other sections in the script. See Variable declarations and Table declarations for details of the declaration syntax. You also use this section to define function prototypes. 


before.program:
Use this section to program actions that must be executed when the session starts. For example, you can use this section to initialize or import variables or to read a special record. Note that the default values or imported values overwrite the fields of the main table.


on.error:
Use this section to program actions that must be executed at the end of the session, before the after.program section. If the session is canceled, the actions in this section are not executed. If an error is detected, you can check the predefined variable e for the error code.


after.program:
Use this section to program actions that must be executed at the end of the session, after the on.error section. If the session is canceled (with the command ABORT.PROGRAM), the actions in this section are not executed. 


after.update.db.commit:
Use this section to program actions that must be executed immediately after a commit.transaction() call, if the database is updated.


before.display.object:
Use this section to program actions that must be executed each time the entire record is displayed.


before.new.object:
Use this section to program actions that must be executed once before the input of the first field of the new created record. It is used for setting the default values of the record fields.


functions:
Use this section to define the functions used in the other sections. This must be the last section in the script. The function syntax is the same as for 3GL functions. 



Example:
declaration:
table tpctst999
long var01, ret


before.program:
if read_parameter() then
mess("pctsts0001", 1) | Parameter not present
stop()
endif


on.error:
mess("........", 1)


functions:
function long read_parameter()
{
select pctst999.*
from pctst999
order by pctst999._index1
as set with 1 rows
selectdo
return(0)
selectempty
return(1)
endselect


}

Related Post:

• 4GL Event Section

Read More

4GL Event Section

A 4GL script can contain one or more of the following types of sections:

• Program sections 
• Form sections 
• Group sections 
• Choice sections 
• Field sections 
• Zoom sections 
• Main table sections 

With the exception of program sections, each section consists of a main section and one or more subsections. A main section indicates the object for which the programmed actions must be executed. A subsection specifies when the actions must be executed. Program sections consist of a main section only.
If you do not include a main section immediately before a subsection, the subsection is assigned to the previous main section in the script. For example:


form.1: | main section 
init.form: | subsection executed for form 1
...
...
before.form: | subsection executed for form 1
...
...
after.form: | subsection executed for form 1


...
The following rules apply to the ordering of sections within a script:

• The declaration section must be the first section in the script.
• The functions section must be the last section in the script. 
• Other sections can occur in any order, but the preferred order is: program sections, form sections, group sections, choice sections, field sections, zoom sections, main table sections.
• Do not mix sections of different types. For example, do not define a choice section, followed by a field section, and then a choice section again. Exceptions are the declaration and functions sections, which must be the first and last sections respectively in the script.

Variables declared in the declaration section are global variables that you can use in other sections. Variables declared within any other section are local variables that you can use in that section only.

Read More

One of its own Kind: Canal Project In India

The western Indian state of Gujarat is all set to become the first state in the country to generate solar power through panels mounted on a water body. Installation of panels on the canal will help in doing away with the need to acquire land. Evaporation of lakhs of litres of water will be prevented since the canal will be covered. And will generate clean energy. Generated solar power will be supplied to villages alongside the canal, which will lead to lower transmission losses and also helping to reduce the evaporation of water.

The solar project is expected to save 100,000 litres of water a year by reducing evaporation of canal water in that particular stretch of one km. Installation of solar panels on river canals would also take care of land issue for solar power project. SunEdison, a subsidiary of US-based global solar energy player MEMC, will be executing the project near Sanand. This is for the first time such a project is being developed in India

Read More

Google is giving respect to Heinrich Rudolf Hertz

Today is the 155th birthday of Heinrich Rudolf Hertz who proved that electricity can be transmitted via electromagnetic waves. 

This discovery of Hertz later proved the way of development of wireless telegraph and radio.Thats why unit of radio frequency is called Hertz.Hertz measured Maxwell's waves and showed how the velocity of radio waves is equal to the velocity of light.Google Doodles are the decorative changes that are made to the Google logo to celebrate holidays, anniversaries, and the lives of famous artists and scientists.

Read More

shiftc$(),shiftl$() and shiftr$()

Syntax
string shiftc$( string strg(.) )
string shiftl$( string strg(.) )
string shiftr$( string strg(.) )


Description
These return the specified string with certain adjustments. 
shiftc$() centers the string by equaling the number of leading and trailing spaces. If there is an odd number of spaces, the extra space becomes a trailing space. The returned string always has the same length as the input string. 
shiftl$() removes any leading spaces from the input string. 
shiftr$() moves the contents of the input string to the right, if there are trailing spaces. The length of the result is always the same as the length of the input string (this is not necessarily the declaration length). 


Note
These functions do not change the input string.


Example
shiftc$("  ABC      ")     | result  "    ABC    "
shiftl$("    ABC    ")     | result  "ABC    "
shiftr$("    ABC    ")     | result  "        ABC"


Related Post:

• String operation

Read More

strip$()

Syntax
string strip$( string_expr )


Description
This returns a specified string without trailing spaces. The input string remains unchanged.


Example
strip$("    ABC    ")      | result  "    ABC"


Related Post:

• String operation

Read More

str$()

Syntax
string str$( num_expr )


Description
This converts an integer or floating point expression to a string. 

Related Post:

• String operation

Read More

pos() and rpos()

Syntax
long pos( string source(.), string pattern(.) )
long rpos( string source(.), string pattern(.) )


Description
These return the start position of a specified substring (pattern) in a specified string (source). source and pattern can be either strings or string expressions. 
pos() starts searching for the substring at the first position in the source string. rpos() starts searching at the last position in the source string. Both return the start position relative to the beginning of the source string. 


Return values
The start position of the substring in the string. Or 0 if the substring is not found. 


Example
long posno
posno = pos("abcdabcd", "bcd")    | posno contains 2
posno = rpos("abcdabcd", "bcd")   | posno contains 6


Related Post:

• String operation

Read More

lval() and val()

Syntax
long lval( string_expr )
double val( string_expr )


Description
These convert a string expression that consists of digits to its numeric representation. 
lval() converts its argument to an integer. If the string contains a floating point number, the result is truncated. val() converts its argument to a floating point number. lval() is faster than val().


Return values
The specified string converted to a long or floating point number. Or 0 if the result of string_expr cannot be converted to a number.


Related Post:

• String operation

Read More

len()

Syntax
long len( string_expr )


Description
This returns the number of characters in string_expr. For strings declared as FIXED, the total length of the string is returned. For non-fixed strings, the current length is returned. To retrieve the length of FIXED strings, excluding trailing spaces, use strip$(). 


Example
long      lng
string    var(20)
string    fix(20)    fixed
var = "abc"
fix = "abc"
lng = len( var )                | Returns 3
lng = len( fix )                 | Returns 20
lng = len( strip$(fix) )     | Returns 3


Related Post:

• String operation

Read More

isspace()

Syntax
long isspace( string_expr )


Description
This tests whether the result of string_expr contains only spaces or is empty. 


Return values
TRUE string is empty or contains only spaces
FALSE     string is not empty and contains characters other than spaces


Example
string str1(20)
if ( not isspace(str1) ) then
message( "'%s' is not empty", str1 )
endif


Related Post:

• String operation

Read More

concat$()

Syntax
string concat$( string separator, expr, ... )


Description
This converts one or more expressions to strings and merges the expressions into a single string. You can use string.scan() to split the string again into its individual parts.
This function is used mainly by the report processor to save unsorted records in a sequential file for subsequent sorting.


Arguments
separator The separator to be placed between individual values in the merged string.
expr ...         One or more expressions of type long, double, or string.


Example
string    ret(100)
long      a
string    b(5)
double    d
a = 10
b = "hello"
d = 1.123456
ret = concat$( "|",a*10,b,d )     | ret now contains "100|hello|1.123456"


Related Post:

• String operation

Read More

String operations

Use these functions to manipulate strings in various ways. For example:

• to check whether a string contains a long value or spaces
• to check the number of characters or bytes in a string
• to load numeric values stored in a string into variables of type long or double
• to convert a number contained in a string to its numeric representation
• to convert an integer or floating point number to a string
• to convert a string to upper case or lower case
• to search for a substring within a string
• to strip leading and trailing spaces from strings
• to align strings
• to store a long or double in a string.

String operations:

• concat$
• isspace
• len()
• lval() 
• val()
• pos()
• rpos()
• str$()
• strip$()
• shiftc$()
• shiftl$()
• shiftr$()

Read More

India: route all emails through servers in india

During a recent high-level meeting held in the office of Union Home Secretary R K Singh, the Department of Information Technology (DIT) ,it is decided that all the  emails will route through the servers located in india even if accounts are not registered in india.However, Yahoo accounts registered outside India and subsequently accessed from India are routed through servers outside India.Some people will definitly think about this that what is the need of this thing but i want to clear one thing that it is done all because of security reasons because few days ago agencies were failed to track the accounts of suspected terrorists.

Read More

Redo Byte Address (RBA)

Recent entries in the redo thread of an Oracle instance are addressed using a 3-part redo byte address, or RBA. An RBA is comprised of 

* the log file sequence number (4 bytes)

* the log file block number (4 bytes)

* the byte offset into the block at which the redo record starts (2 bytes) 

RBAs are not necessarily unique within their thread, because the log file sequence number may be reset to 1 in all threads if a database is opened with the RESETLOGS option. 

RBAs are used in the following important ways. 

With respect to a dirty block in the buffer cache, the low RBA is the address of the redo for the first change that was applied to the block since it was last clean, and the high RBA is the address of the redo for the most recent change to have been applied to the block. 

Dirty buffers are maintained on the buffer cache checkpoint queues in low RBA order. The checkpoint RBA is the point up to which DBWn has written buffers from the checkpoint queues if incremental checkpointing is enabled -- otherwise it is the RBA of last full thread checkpoint. The checkpoint RBA is copied into the checkpoint progress record of the controlfile by the checkpoint heartbeat once every 3 seconds. Instance recovery, when needed, begins from the checkpoint RBA recorded in the controlfile. The target RBA is the point up to which DBWn should seek to advance the checkpoint RBA to satisfy instance recovery objectives. 

The on-disk RBA is the point up to which LGWR has flushed the redo thread to the online log files. DBWn may not write a block for which the high RBA is beyond the on-disk RBA. Otherwise transaction recovery (rollback) would not be possible, because the redo needed to undo a change is always in the same redo record as the redo for the change itself. 

The term sync RBA is sometimes used to refer to the point up to which LGWR is required to sync the thread. However, this is not a full RBA -- only a redo block number is used at this point. 

The low and high RBAs for dirty buffers can be seen in X$BH. (There is also a recovery RBA which is used to record the progress of partial block recovery by PMON.) The incremental checkpoint RBA, the target RBA and the on-disk RBA can all be seen in X$TARGETRBA. The incremental checkpoint RBA and the on-disk RBA can also be seen in X$KCCCP. The full thread checkpoint RBA can be seen in X$KCCRT

Read More

VLC's new version VLC2.0 with super updates

VLC is a portable multimedia player, encoder, and streamer supporting many audio and video codecs and file formats as well as DVDs, VCDs, and various streaming protocols.

VLC 2.0 is also addressed as "Twoflower" in a software market.It is one of the most platform-independent players available.It has ability of faster decoding on multi-core, GPU, and mobile hardware and the ability to open more formats, notably professional, HD and 10bits codecs.It also includes Multi-threaded decoding for H.264, MPEG-4/Xvid and WebM,Rewritten support for images, including jpeg, png, xcf, bmp,New video outputs for Windows 7, Android, iOS and OS/2,New audio outputs for iOS, Android and OS/2.


Download From This Link:

• VLC 2.0 Download

Read More

What is an Iterator interface?

The List and Set collections provide iterators, which are objects that allow going over all the elements of a collection in sequence. The java.util.Iterator<E> interface provides for one-way traversal andjava.util.ListIterator<E> provides two-way traversal. Iterator<E> is a replacement for the olderEnumeration class which was used before collections were added to Java.

Creating an Iterator

Iterators are created by calling the iterator() or listIterator() method of a List, Set, or other data collection with iterators.

Iterator Methods

Iterator defines three methods, one of which is optional.

Result	Method	Description
b =	it.hasNext()	true if there are more elements for the iterator.
obj =	it.next()	Returns the next object. If a generic list is being accessed, the iterator will return something of the list's type. Pre-generic Java iterators always returned type Object, so a downcast was usually required.
	it.remove()	Removes the most recent element that was returned by next. Not all collections supportdelete. An UnsupportedOperationException will be thrown if the collection does not support remove().

Example with Java 5 generics

An iterator might be used as follows.

ArrayList<String> alist = new ArrayList<String>();

// . . . Add Strings to alist

for (Iterator<String> it = alist.iterator(); it.hasNext(); ) {

    String s = it.next();  // No downcasting required.

    System.out.println(s);

}

Example as above but with enhanced Java 5 for loop

for (String s : alist) {

    System.out.println(s);

}

Example pre Java 5, with explicit iterator and downcasting

An iterator might be used as follows, wi.

ArrayList alist = new ArrayList(); // This holds type Object.

// . . . Add Strings to alist

for (Iterator it = alist.iterator(); it.hasNext(); ) {

    String s = (String)it.next();  // Downcasting is required pre Java 5.

    System.out.println(s);

}

Read More