app designer brining in variables from a script

Hopefully I can explain this:

I am working on an app where the user can load in csv files. The csv files are vehicle data from CANbus and so naturally, different vehicles can have different header names for the same thing like vehicle speed. The data are read in using readtable, so normally in my typical matlab script, the data comes in as a table.

So my idea was, once the user had loaded in the vehicle data. They would then load in a script file that contained the right mappings. So what I am trying to do is map the differing names to some standard names that can then be used throughout the app.

But I am a bit stuck on how you actually get them in. I know you can use run() to run the script, but obviously you can't see the variables.

would I add my standard names in the app as properties first? so for example: app.VehicleSpeed.

Then in the script i have app.VehicleSpeed = app.importedfile.CANbus_name?

[Kevin Holly]

You could turn the script into a function MATLAB file and call it with the variables you need as the inputs. Also, run() is not needed to run your script. You could just type the name of the script.

For the function inputs, you do not need to use the app's property variables. If the function is called within one of the app's callback function and all variables are in that callback's workspace, then you just simply input the variables into the function. If you want to use properties variables as inputs, you could use them as inputs to the function as a single variable (app.variable) or as a structural array (app), which you can use to call all the app's properties within your function. Let me know if you would like me to provide an example.

[Alex Mason]

Hi Kevin,

yeah an example might be helpful, struggling to get my head around it.

The thing is these bits of data which will have names unique to a particular vehicle are "mapped" to a standard name that is then used through out. But they won't just be used within one call back. They'll be used and manipulated in many different call backs. - My app has stages and this data is passed along each stage and manipulated, saved and moved on to the next.

I think what I needed is someway that these things are mapped into a global variable that can be used by whatever part of the app is necessary.

Answer 1

[Kevin Holly]

Alex,

I have attached an app that loads Excel data as a table and then calls a live function called "TableConverter" that replaces the heading variables names of the table. When I called the function, I placed the table variable as the input. I did not use app properties. If I did choose to do this, I could call a table that is saved as a properies, such as "InputTable", into the function and then call it with "TableConverter(app.InputTable)" . Alternatively, I could place all the app's property variables into the function by with the command, "TableConverter(app). Then within the function, I could access a particular variable such as "app.InputTable".

[Alex Mason]

Hi Kevin, thanks for this. I will take a look shortly. I had not thought about changing the headers in the table itself.

[Alex Mason]

Hi Kevin,

I think I can work with this now that I understand it. Many thanks.

I think I could expand it by passing a filename, filepath for a .m file that will contain all the "from" and "to" variable name strings. So in your function where the switch case has "Var1", "Var2" these can just be the items kept in that 'm file. So I can have a file for each different vehicle.

Then modify to send back the input file in original state, plus an output table that just has the changed names in (like a working data table).

Is there any reason you went with "Switch case" rather than say, just loading the column headers as a cell of strings and the using strfind or srrep instead? My concern is, if I have files with 100+ columns I don't want it to take a long time.

Many thanks

[Kevin Holly]

I wasn't sure how much manipulation was involved when converting the table. I wasn't sure how complicated the script you were using was. For instance, you may have needed to import the data as an array, tranpose the matrix, and then convert the array to a table with an array2table function. Or you might have filtered the table for certain values related to a header. Or you might have multiplied the values by let's say a thousand for it to be equilivant to another header or multiply them by a constant for unit conversion. That is why I used a switch case, to leave room for addtional changes to table.