Interface and Description |
---|
org.vishia.cmd.CmdGetFileArgs_ifc
new concept is
CmdGetterArguments . This class is too restricted. |
org.vishia.mainCmd.MainCmd.SetArgument
the newer form is
Arguments.SetArgument , use this for new development. |
Class and Description |
---|
org.vishia.util.Assert
use
ExcUtil |
org.vishia.byteData.ByteDataAccess
use
ByteDataAccessBase for new Algorithm. This is the original code from 2014-01-13, only formally adapted.
The ByteDataAccessBase contains the same wideness, but with the concept of prevent using virtual methods and with a given size of head.
That is better than the ByteDataAccess.specifyLengthElementHead() as virtual method especially for usage in C. |
org.vishia.byteData.ByteDataAccessDbg |
org.vishia.byteData.ByteDataAccessOld
since 2012, use
ByteDataAccessBase |
org.vishia.util.CheckVs
use
ExcUtil |
org.vishia.msgDispatch.ExceptionInfo
see
org.vishia.util.Assert#exceptionInfo(String, Throwable, int, int) |
org.vishia.util.FilePath.XXXZbnfFilepath
This is the only one reason that the fields of FilePath are fine graduated. It saves calculation time
if a better algorithm is used. This class will be removed if the
org.vishia.zcmd.JZtxtcmdScript and its syntax
does not need it anymore. |
org.vishia.util.FileWriter
use instead
FileAppend |
org.vishia.header2Reflection.Header2Reflection |
org.vishia.communication.InterProcessCommFactoryAccessor
the InterProcessCommFactory contains all capability.
|
org.vishia.zcmd.JZcmd |
org.vishia.mainCmd.MainCmd |
org.vishia.mainCmd.MainCmd.Argument
the newer form is
Arguments , use this for new development. |
org.vishia.util.OrderListExecuter
use
EventTimerThread |
org.vishia.cmd.PrepareCmd
since 2016-12. Use the
JZtxtcmdExecuter instead. It has more capability. |
org.vishia.byteData.RawDataAccess |
org.vishia.util.StringPartFromFile |
org.vishia.zbnf.ZbnfXmlOutput
since 2012-11 because the
ZbnfParser.getResultTree() provides an XML tree already.
The SimpleXmlOutputter can be used instead.
Example see Zbnf2Xml |
Constructor and Description |
---|
org.vishia.byteData.ByteDataAccessBase(int, int)
Remark: Because
ByteDataAccessBase.assign(byte[], int) decides on the size of data, and ByteDataAccessBase.addChild(ByteDataAccessBase, int)
decides on the size of data of a child, this constructor makes no sense. Jchartmut 2015-04-12 |
org.vishia.util.CalculatorExpr(String, Map<String, DataAccess.IntegerIx>, Class<?>)
it should be possible to use
#CalculatorExpr(StringPartScan, Map, Class) in all cases. |
org.vishia.util.CalculatorExpr.Operand(String, Map<String, DataAccess.IntegerIx>, Class<?>, Map<String, Object>)
it should be possible to use
Operand#Operand(StringPartScan, Map, Class) in all cases. |
org.vishia.byteData.ByteDataSymbolicAccess.Variable(ByteDataSymbolicAccess) |