I want to create a new SCL function with TIA 15.1. I chose Program blocks => Add new block => Function. When I write the keyword FUNCTION in my file I get the following error: tag FUNCTION not defined. This is the same for others keywords like VAR for example.
My Code:
FUNCTION "test" :Void
VAR
V1: Bool;
END_VAR
END_FUNCTION
I searched the web but there is not a lot of documentation on the topic.
Any idea to solve the problem?
By default the way you need to do this is a little different than the old stuff. You need to define your variables in the table and and just write code in the editor. You don't add the function, var, var_in, etc. keywords.
However, new to V15.1 you can select text view under Options->Settings->PLC Programming->SCL->Interface and select Text view. If you create a new function now it will let you enter the variables using var, var_in, etc. But make sure you create a new function block. Also, this only works with SCL.
Related
I'm trying to overwrite the parameter handler, so it'd point to another temp-table with different schema.
myProcedure.p
DEFINE TEMP-TABLE TT_RealTable NO-UNDO
BEFORE-TABLE TT_RealTableBefore
FIELD name AS CHAR
.
DEF INPUT-OUTPUT PARAM TABLE-HANDLE TH_NewTable.
CREATE TT_RealTable.
ASSIGN TT_RealTable.name = "Ben".
CREATE TT_RealTable.
ASSIGN TT_RealTable.name = "Harry".
The TH_NewTable points to a random parameter TEMP-TABLE with different schema and contents. I want to overwrite this parameter TABLE-HANDLER with the TT_RealTable. If I try to set:
TH_NewTable = TEMP-TABLE TT_RealTable:HANDLE.
The program will crash at runtime saying that TT_RealTable's schema/meta data doesn't match the handler's one.
How I can overwrite the handler to point to my TT_RealTable:HANDLE, and return it as output?
If the schema IS different as the error claims, and you said at the beginning of your post, what you want to do can't be done. You can't pass a temp-table buffer handle that has a certain definition and return something else at the end of the procedure, assuming the parameter table handle is from a static temp-table. Even if it isn't, you'd need to create the temp-table using the buffer handle AFTER calling the procedure, which I'm thinking is not what you want, since your parameter is input-output.
If you really want to work with a table that's fluid as far as schema goes, you should read into dynamic temp-tables. Look for the CREATE TEMP-TABLE statement in help and read through the examples to understand how you can get a handle and then (and only then) build a temp-table using the returned handle, so you can use that. You lose the ability of using regular statements, though, such as create and assign. You'll have to reference BUFFER-FIELD and BUFFER-VALUE, and use the CREATE method instead, using the buffer-handle. Might take a while to get used to it, but it's not rocket science.
Hope it helps!
I work on an Access VBA 2013 application, and this part of the project focuses on form controls and buttons.
I want to lock/unlock control modification thanks to buttons set aside.
For more genericity, I wanted the subs called by the events call homemade functions:
Sub LockAssociateControl(fctName As String, val As Boolean)
Dim code As String
code = "Forms!" & getModuleName & ".Controls!" & fctName & ".Locked = " & CStr(val)
Debug.Print (code) 'just to test
Eval code
End Sub
(getModuleName is also a homemade function that returns the right name of the module calling the function)
For example, this one is called like below:
Private Sub FirstName_Exit(Cancel As Integer)
Call LockAssociateControl("FirstName", True)
End Sub
and in "code" variable, it sets "Forms!Module1.Controls!Name.Locked = True" (with Module1 generated by getModuleName, and Name as the parameter (I haven't found better yet)).
Now I want this code evaluated in order to avoid me from hard coding every event sub.
My problem is that an error occurs at the Eval() line and says:
Error Code: 2770. The object to which you reffered in the Visual Basic procedure as an OLE object is not an OLE object
I've looked around StockOverflow and others forums to find out what's wrong with Eval(), and I found that this function's behavior is not made for what I want. So I tried to find another way to do that, as Evaluate function doesn't exist in Access, etc, but I found nothing really helpful.
I tried to use DoCmd or Call or various transformations on the parameter string of Eval(), but nothing has worked so far...
So here's my question: Do any of you have a solution for that problem? And if not, do you know an alternative not to have to write in every event function full statements like: Forms!Module1.Controls!Name.Locked = False?
You can do what you want easier without using Eval() ...
Sub LockAssociateControl(fctName As String, pVal As Boolean)
Forms(getModuleName).Controls(fctName).Locked = pVal
End Sub
Note I changed the argument name from val to pVal to avoid confusing it with the Val() function.
I created this function to browse all the functions stored in a file and now I want to select my function in my main program how can I select it
This is my function:
function testMode(i)
a=dir('H_*.m');
if exist('i','var')
if isempty(i)
z={a.name}';
[selection,ok]=listdlg('ListString',z,'SelectionMode','single');
if ok
i=find(selection,1,'first');
end
end
nom=a(i).name;
nom=nom(1:end-2);
disp(nom)
else
disp('fonction a un argument')
end
It looks like you will have the name of the function as a string. To call that function, you can either use feval, or you can convert the string to a function handle and call that.
result = feval(nom, argument1);
or
fcn = str2func(nom);
fcn(argument1);
The latter should be preferred, as the conversion can be done once and the function handle re-used after that, and because the calling syntax is exactly the same as calling a regular function.
For more information on function handles, see doc function_handle.
Also, for a different approach, see this document: http://www.mathworks.com/help/matlab/ref/localfunctions.html. If you can create your "menu" of functions as local functions in a single file, this approach could be very clean and simple, as it will directly give you a cell array of function handles of all of those subfunctions. From there, you can get easily get the function name for display using functions command.
I want to use doxygen to document a c-like language.
I got some issues to solve keywords which are unknown in the context.
One example, I have to use a callback function called
on timer
{
//normal c- code
}
My question is now, can I adopt doxygen to accept the new keyword?
I would like to add this keyword like a function or variable acc. to
/** This timer is used for something. */
on timer
{
}
or maybe
/** \ontimer This timer is used for something. */
on timer
{
}
The documentation of doxygen describes something with ALIASES or \xrefitem but as I understand I can only generate new sections for known types or am I wrong?
Actually I am surrounding the unknown code with a condition block out to avoid errors in the generated output.
As I understand is "on" a keyword which doxygen cannot interpret. One solution could be to declare the keyword on as a predfined macro in the doxyile by using the the PREDEFINED tag as follows:
PREDEFINED = on=
Yes, the = at the end is not a typo! This tells the preprocessor of doxygen to substitute the keyword on with a empty string. Note that you have to set ENABLE_PREPROCESSING to YES.
If the on keyword only appears before callback functions you could alternatively set the PREDEFINED macro to void:
PREDEFINED = on=void
As noted here, functions in packages, as well as static methods in classes, still need to use a packagename.functionname syntax or import packagename.* for each function (since the imports are part of the function workspace and not global). This means that changing the package/class name later on can become a tedious nuisance.
Is there any way to do something like import this.*, i.e. a package/class name agnostic method to access all functions/static methods in the same package/class?
So... doesn't this require importthis to also be imported? Or is importthis a function you always have in your path?
It seems hardly more complex to just paste an "import this" block with this at the top of each function, and then you don't have to worry about importthis being in your path. I tend to feel that reliance on path is dangerous.
"Import This" block
%% Import own package
[~, pkgdir] = fileparts(fileparts(mfilename('fullpath')));
import([pkgdir(2:end) '.*']);
You can even put it in a try/catch block to make sure it's in a package directory, and decide what to do if it's not.
%% Import own package
try
[~, pkgdir] = fileparts(fileparts(mfilename('fullpath')));
import([pkgdir(2:end)'.*']);
catch err
if ~strcmp(err.identifier,'MATLAB:UndefinedFunction'), rethrow(err); end
end
I recently ran into a similar problem and found the following solution for packages. However it is VERY hacky.
You create a function called import this with an optional argument.
function to_eval = importthis(exclude_list)
if nargin == 0
exclude_list = [];
end
var_name = genvarname('A', exclude_list); %avoid shadowing
to_eval = ['[~,'...
, var_name...
, ']=fileparts(fileparts(mfilename(''fullpath'')));'... %get containing dir
, 'eval([''import '','...
, var_name...
, '(2:end),''.*'']);'... %remove '+'
, 'clear '... %clean up
, var_name
];
end
This function returns a string which can then be evaled that imports the "this" package. So in your package functions you would put the following near the top:
function B = myfunc(A)
eval(importthis);
%function body
end
You can also pass who to importhis, leaving your function's namespace clean.
function B = myfunc(A)
eval(importthis(who));
%function body
end
I can't decide whether I should feel proud or discusted by what I did.
This probably is not a bounty worthy answer but as you do not have any answers I thought I would post it anyway! You can invoke static methods via an instance of the class which you would only need to define once. You can invoke functions via a function handle but this would require one handle per function.
Using these techniques you could define all your static method and function references in one place. Then you would use these references throughout your package. Then if you decided to change the package name at a later point you would only need to update these references which are all stored in one place.
See:
Calling Static Methods
You can also invoke static methods using an instance of the class,
like any method:
obj = MyClass;
value = obj.pi(.001);
function_handle (#)
The following example creates a function handle for the humps function
and assigns it to the variable fhandle.
fhandle = #humps;