Dynamic programming user interface question...

Hi forum:
I´m creating radiobuttons dinamically, i saw the next reference, and it´s good but that´s examples suppose that i have a simple type charged with some data enumerated, and also my data are dinamyc beacuse i get it from a XML file.
http://help.sap.com/saphelp_erp2005/helpdata/en/07/73a840bd6d3c13e10000000a155106/frameset.htm
I mean, when i have to create a node dinamically i have to describe de datatype, but this data type for a RadiobuttonGroupByKey in the examples comes from a simple type previously filled, and my data is dinamically...
Some body can help me, please?
Thnks
Josue Cruz
Message was edited by: Josue Cruz

Josue,
1. For radio buttons & radion buttons group by key:
final IWDAttributeInfo attr = <node>.getNodeInfo().getAttribute("<attr-name>");
final ISimpleType type = attr.getSimpleType();
final ISimpleValueServices svSrv = type.getSVServices();
final ISimpleValueSet svSet = svSrv.getValues();
svSet.put("ke1", "val1");
svSet.put("ke2", "val2");
svSet.put("ke3", "val3");
2. Why not to simply use RadioButtonGroupByIndex? This way you may skip all dynamic UI programming and simply populate necessary node with your data.
Valery Silaev
EPAM Systems
http://www.NetWeaverTeam.com

Similar Messages

User Interface Questions

I have already programmed some dialogs in JavaScript. I'm not using Script UI, although I've played around with Script UI a little bit. Now I'm getting a bit more advanced with some user interfaces and dialogs and have a few questions:
1. Is it possible to create a "live updating" dialog similar to InDesign's Files > New > Document, where based on a menu selection of a preset, the dialog's editboxes change their values to reflect that menu selection?
2. Can you program something like the Presets button in InDesign's New Document dialog where the user clicks "Save Preset", names it, and then the main dialog updates with the new preset the user just created.
3. Script UI does not have measurement friendly boxes, does it? By that I mean that when you enter inches, mm or picas, the box will translate it into the current measurement type.
4. I love the nudge option on the measurement editboxes. Can that be done via Script UI?
Ideally my coding needs to work in both CS2 and CS3 and I code in JavaScript because that's what I know, but if the "live updating" stuff is possible in AppleScript or VBScript I'd still like to be aware that it can be done.
While code examples of any of this are welcome, I mostly need to know what's possible, and any starting point you can offer will help (like the name of the control). That way I can start looking things up and figuring them out.
Thanks in advance,
Dan

Thanks for the answers Bob. They are exactly as I thought, but wanted to make sure. It sucks that we have to recreate (via code), things that were given to us before Script UI. I know Script UI is more powerful in some ways (and hopefully sure will get more powerful with time) but loosing measurement boxes is a big bummer. They had so many nice built in features. I feel like I need to reinvent the wheel with Script UI.
1. Do you have any example dialogs that you could post? I can often figure out how to get a lot of stuff done by looking over examples other people have created. Especially things where one feature interacts with another, but even just a dialog with menus, text, etc so I can check out how to layout the dialog. I have created one dialog with Script UI, but am not sure if I am doing it very efficiently and I couldn't find any Script UI stuff in InDesign's sample scripts.
2. I suspect if I use Script UI I'll have to verify that only numbers are entered into the edit fields right? I need numerical values only for what I will be doing. Any thoughts on the best way to verify it's only a number in there? Can I do that live in the dialog before the user clicks OK? Argh, all these complications make me less than enthusiastic to go to Script UI, but I really would like to be able to have a live updating dialog.

How do I receive notification of a change in the value of a dynamically created user interface object?

I need to know when the user has changed the value of a slider or a Boolean control that was dynamically created (not part of a dialog). Is there any way to do that without polling? I would have expected these controls to post a WM_NOTIFY message to the parent window in response to user events, but that does not seem to happen. Am I missing something?

Win32 controls do typically post WM_NOTIFY messages to the parent window for user events. The Measurement Studio UI controls are actually ActiveX controls, though, and events are handled differently for ActiveX controls.
If you have a resource ID for you control, the easiest way would be to create your control in the OnInitDialog method and handle the event the same way you would if you had added the control to the dialog at design-time:
Add a declaration for the event handler in the AFX_MSG block in the dialog header file.
Make sure the AFX_MSG block in the header file includes DECLARE_EVENTSINK_MAP()
Include an ON_EVENT entry for the event in the dialog source's BEGIN_EVENT_SINK_MAP block.
Include a DDX_Control entry
in the dialog source's AFX_DATA_MAP block.
Otherwise, you'll have to dynamically sink the event at runtime after you've created the control. Microsoft's Knowledge Base has a couple of good articles that demonstrate how to do this:
SAMPLE: AtlEvnt.exe Creates ATL Sinks Using IDispEventImpl (Q194179)
AtlSink Uses ATL to Create a Dispinterface Sink (Q181277)
- Elton

Dynamic user interfaces

Hello,
here's a little teaser for user interface experts out there:
I wonder what kind of techniques ABAP offers for creating dynamic user interfaces.
When talking of 'dynamic' I imagine something like an arbitrary number of 'containers' where other programs (classes f.ex.) can draw their own user interface into.
In Java this could be realized with the container concept in swing.
I have done some research on this topic and the results are so far:
a plain dynpro: seems to have no dynamic at all -> not an option
a plain dynpro with a tabstrip: in case the number of tabs CAN be set at runtime AND the subscreens CAN be drawn from inside separate classes -> a definite option otherwise not an option
any kind of web-frontend (BSP, JSP etc.): web-frontends are not allowed by company restrictions -> not an option
dynamic documents: I could not find many information on these yet (also not on sdn). In case that an arbitrary number of parts of the dynamic document can be created from inside separate classes -> an option otherwise not an option
I will be happy about any further information on this topic.
Best regards,
Patrick Baer

I spent some time today doing research on BSP's and built a "BSP-Viewer" embedded into the SAP-GUI. Though I like the concept of BSP's a lot (like I did already with JSP's) but company restricitions are too strict. So BSP's are out of the play.
After the discussion I started to play around with the different containers and basically I'm quite pleased with them and the "cl_gui_container_bar" allows an arbirtary number of "subscreens" which matches my requirements.
But as usual there's still a downside:
I found no option to built text labels and text fields into a container. Unless this is possible I can't give this approach a chance. I already found some postings which seemed to confirm that this is in fact not possible but I can't really believe it. At least from what it looks like it seems to me that the object navigator utilizes both: splitters, containers and all the stuff AS WELL AS the "classical" elements like text boxes, labels and so on.
Any ideas on how to combine the container concept with text fields, labels maybe whole dynpros or subscreens ?
Best regards,
Patrick Baer

Dynamic user events freeze user interface

Hi all,
I am having problem with dynamic user events.
Dynamic user event is registered to the event structure, and many dynamic user events come in very fast, about every 30 ms. It freezes up the user interface, no response to mouse and keyboard, even after all user events finish execution.
Any idea or work around?
Thanks for any help.
Anne

Hi Anne,
> Dynamic user event is registered to the event structure, and many dynamic user events come in very fast, about every 30 ms.
The 30ms rate is not unreasonably fast as long as the processing for the event(s) can be completed in less than 30ms.
What tasks are you doing in the User Event?
For tasks that may take time to complete (like logging) you could queue up the data and send it to a consumer loop.
> It freezes up the user interface, no response to mouse and keyboard, even after all user events finish execution.
My *guess* here is that you got stuck in an event that never completed.
steve
Help the forum when you get help. Click the "Solution?" icon on the reply that answers your
question. Give "Kudos" to replies that help.

User-Interface tab control question

Heey everyone,
I`ve disigned a program and a user interface, on this user interface there is a tab control (see attachement) in this tab control you can select several measurements. This is a school project and according to my teacher it isn`t clear enough which measurement is chosen.
My question: Is there a way to give the active tab a different color? If not then do you know a way to create a nice user-interface which has the same abilities as the tab control (select measurement and fil in values for the measurement).
Thank you
Currently using labview 8.2.1
Solved!
Go to Solution.
Attachments:
tabcontrol.JPG ‏211 KB

Hi Grasman,
it is possible to give different Tabs different colors, first you should activate Multiple colors - "Right-click on a tab on the control. Select Advanced » Allow Multiple Colors.
To change only the color of the active tab, please see Steve Birds VI, you can find this on the following forum post
Active Tab Color
Regards,
Tobias

BPM Workspace Customization & User Interface: Best Practice Question

Hi All,
This is our first BPM Project in house and we are on Oracle BPM 11g.
The business process involves request for approval for a permit from a public user and internal users need to approve/reject the same. Pretty simple and straightforward so far.
But we are now having lots of questions wrt to user interface.
1. Work Space Changes.
If we develop this application completely in Oracle BPM, the outside user (general public) will also see the 'workspace' with its current interface. It would be impossible to handle user training on this interface for a simple Joe Bloe, who may not be computer savvy) So the requirement documents demand that the look and feel of the outside users should be totally different than what the workspace provides. They want this to be customized in such a way that iit would strip all of the default lay out (left navigation bar, and get rid of the upper section completely. with its list of tabs) and also to modify the task list that appears below).
We have figured out how to achieve this (by modifying the workspace .jar files and recompiling the same), but is this a good approach? What happens if we are developing a brand new application on the BPM in our shop? This change will affect that application as well, as the workspace is shared and common to all the apps? I want some of you experts to let us know, your thoughts on this. If this is not a recommended practice, what would be best way to achieve what we want using Oracle BPM? (Where we want a simple intuitive user interface, without the default add ons that comes with the work space)...
2. What would be the best method to create a user registration page (where a user creates his own login and password and maintains his account) for an application using the BPM ? Right now we are thinking this should be in either a ADF page/ JSP page or (worst case a PL SQL cartridge) that can be launched on the browser, which will be open and does not require any kind of authentication to access. Is this a good practice or recommended one? Or are we missing out on something within BPM application itself, that we are not aware of and that would let us do this?
3. Also, if we go with an external ADF application for the 'public' user interface developement, then how can we (or can we) leverage the BPM's internal storage for the submitted data from the payload? I understand that it stores this information currently on the server 'soa infra' tables some where? Thru an external ADF app, can we write into these tables (Is this recommended or just sounds plain ridiculous)???
Knowing answers to these questions will help us decide, if this is the right tool for the job at hand.
Appreciate your time and xpertise.
Thanks
SR

Hi All,
This is our first BPM Project in house and we are on Oracle BPM 11g.
The business process involves request for approval for a permit from a public user and internal users need to approve/reject the same. Pretty simple and straightforward so far.
But we are now having lots of questions wrt to user interface.
1. Work Space Changes.
If we develop this application completely in Oracle BPM, the outside user (general public) will also see the 'workspace' with its current interface. It would be impossible to handle user training on this interface for a simple Joe Bloe, who may not be computer savvy) So the requirement documents demand that the look and feel of the outside users should be totally different than what the workspace provides. They want this to be customized in such a way that iit would strip all of the default lay out (left navigation bar, and get rid of the upper section completely. with its list of tabs) and also to modify the task list that appears below).
We have figured out how to achieve this (by modifying the workspace .jar files and recompiling the same), but is this a good approach? What happens if we are developing a brand new application on the BPM in our shop? This change will affect that application as well, as the workspace is shared and common to all the apps? I want some of you experts to let us know, your thoughts on this. If this is not a recommended practice, what would be best way to achieve what we want using Oracle BPM? (Where we want a simple intuitive user interface, without the default add ons that comes with the work space)...
2. What would be the best method to create a user registration page (where a user creates his own login and password and maintains his account) for an application using the BPM ? Right now we are thinking this should be in either a ADF page/ JSP page or (worst case a PL SQL cartridge) that can be launched on the browser, which will be open and does not require any kind of authentication to access. Is this a good practice or recommended one? Or are we missing out on something within BPM application itself, that we are not aware of and that would let us do this?
3. Also, if we go with an external ADF application for the 'public' user interface developement, then how can we (or can we) leverage the BPM's internal storage for the submitted data from the payload? I understand that it stores this information currently on the server 'soa infra' tables some where? Thru an external ADF app, can we write into these tables (Is this recommended or just sounds plain ridiculous)???
Knowing answers to these questions will help us decide, if this is the right tool for the job at hand.
Appreciate your time and xpertise.
Thanks
SR

Programming a User Interface

Hi everyone!
I apologize for posting this here - it may be completely off topic. To alleviate this problem, I'm offering the maximum number of Duke Points I can if anyone can provide an adequate answer. I hope that's okay. :)
I'm going into international development in university and am starting a research project dealing with User Interfances, Software Internationalization, and its impact on development.
Does anyone know of any XML-based APIs for Java and other programming languages that allow for creation of user interfaces with the purpose of facilitating translation?
Thank you!
- Wojciech

Or maybe because the noob just moved from his home to
his university residence and has been dealing with
that for the last week or so. :)LOL. Moving is pain - no two ways about it. Hopefully you get settled soon... :o)
I appreciate your help and will be looking at all the
info once I have Internet access on my laptop again -
should be within a few days.Good luck - I don't know if the links will do you any good, but they're tutorials/references I've collected for dealing with internationalization.
§

Developing a User Interface with ADF Faces - Tutorial - Questions

Hello everybody,
I am a forms developer and I am totally new to ADF.
I started from the tutorials : Developing Business Services with ADF BC and Developing a User Interface with ADF Faces...
Everything was easy and very clear, as far as the material covered in the tutorial is concerened.
But when I tried to modify a little bit the application, to perform a different task... disaster!!! :-)
One of the "simple" things that I tried to do -for example- is :
In the login.jspx, where we have created an ADF Parameter form (that accepts as a parameter the customer ID) and
retrieves in the next page the Orders of the specific customer.... to Display a message, such as "+Customer Does Not Exist+"
if the user types in the parameter form an not existent customer ID...
I understand that I should use a validator.... But I cannot find the list validator (from query) in the bind variables not in the ADF Parameter Form Fields....
Does anyone know?
Regards,
Maira Kotsovoulou

Dear Grant,
CustomerID is in the UI Project, and appears as a part of an ADF Parameter Form... and I can not find key exists in the UI Validators....
CustomerID in the .entities is a bind variable in a query. select ... from customers where customer_id = :p_customer_id. Again KEYEXISTS validator is not available in the bind variables sections... Only in the attributes!!!
I understand that the "normal" behavior in a query with bind variables where there is no match is to display nothing as it does!!!
But I was just wondering, if I could even trap that before I display the empty form...? Or could I display a text in my ADF form, that says no rows... (as I can do in an ADF Table???)

Why do I get -18001 Errors using Customised TestStand User Interface

Hi all
I have a problem when attempting to run my application on my host NT PC. I have a customised operator interface to TestStand written using Labview 5.1.1 and built using the LabVIEW application builder. I am running the TestStand Development (Run-Time) System on my host PC.
The problem is that as soon as I go to run my sequence of vis (mass compiled using the same version of LabVIEW and assembled for run-time distribution) I receive the error '-18001 VI Not Executable.'
I think this is probably to do with how I've included the ActiveX server in my LabVIEW User Interface application, but knowing very little about ActiveX I'm not sure exactly what the problem is.
If anyone
has any ideas, I would be extremely grateful for any assistance you could offer. My TS version is 1.0.1
Thanks
Dave

David,
I would like to add to Richard's input. The typical reasons a VI cannot be executed that cause this message are:
1) There is an error in the VI such that the run arrow of the VI is broken when the VI is open in the LV development environment. This problem is usually easy to debug because you should get the error (shown below) when running your sequence in the sequence editor using the default "LabVIEW" ActiveX server provided by the LV development environment (not the LV ActiveX server provided by your operator interface which is by default named "TestStandLVGUIRTS" ).
An error occurred in the 'MyVIStep' step of the 'MainSequence' sequence in 'MySequence.seq'.
LabVIEW : VI is not executable.
An error occurred accessing the LabVIEW ActiveX automation server. Error Code: -18001
2) The same error will occur when
a. you are using any LV ActiveX server other than the "LabVIEW" server provided by the LV development environment, AND
b. at least one of the called VI was not assembled for distribution properly. This means that not all test VIs and their *entire* hierarchy were distributed.
I am not sure exactly what you have done so have compiled some information that I think will help. Below I have included the document, Overview of Distributing TestStand when your Sequences use the LV Standard Prototype Adapter, which will appear in the NIDZ shortly. Another useful document is the NIDZ document Distributing LabVIEW Test VIs, which you can obtain from our website. Read these documents before preceding with the steps immediately below, which give you an example process for distributing. This may help provide a better understanding and guidance in the distribution process. We are working to simplify this process in future versions of TestStand.
For the following example distribution I recommend that you are use default shipping code so that the problem is not complicated with potential errors added through customizations you have made.
Building The Operator Interface
The following are steps if you are using a LabVIEW operator interface.
1) Copy the contents of \OperatorInterfaces\NI\LV to \OperatorInterfaces\User\LV.
2) Open a new VI in LabVIEW. Make sure all other VIs are closed.
3) In LabVIEW Select Tools>>Build Application or Shared Library
4) In the builder click the Load button and load \OperatorInterfaces\User\LV\testexec.bld. This build script is configured to create testexec.exe that contains the LV ActiveX server with the name of TestStandLVGUIRTS (see the Application tab of the builder).
5) In the builder click Build.
6) Once the application testexec.exe is built, run it once so that the server TestStandLVGUIRTS is automatically registered. You do not need to run a sequence. Close texec.exe.
Creating a LabVIEW Run-time Server
If you are using the LabVIEW operator interface then skip this section. The following steps are meant for those who use an operator interface written in a ADE other than LabVIEW. They provide you with a LabVIEW run-time server that is used by TS to run your VIs.
1) Copy the contents of \Components\NI\RuntimeServers to \Components\User\RuntimeServers.
2) Open a new VI in LabVIEW. Make sure all other VIs are closed.
3) In LabVIEW Select Tools>>Build Application or Shared Library
4) In the builder click the Load button and load \Components\User\RuntimeServers\LabVIEW\TestStandLVRTS.bld. This build script is configured to create TestStandLVRTS.exe that contains the LV ActiveX server with the name of TestStandLVRTS (see the Application tab of the builder).
5) In the builder click Build.
6) Once the application TestStandLVRTS.exe is built, run it once so that the server TestStandLVRTS is automatically registered on your development machine. Close TestStandLVRTS.exe.
Assembling the Test VIs for Run-Time Distribution
This distribution process uses one of the shipping TS examples that calls LV VIs.
1) From LV mass compile all VIs in the directory \Examples\AccessingArrays\UsingLabVIEW\. Please make sure that there were no error messages in the Status tab of the Mass Compile dialog box.
2) In the sequence editor open \Examples\AccessingArrays\UsingLabVIEW\AccessingArrays.seq
3) Confirm that the sequence runs without problem.
4) In the sequence editor select Tools>>Assemble Test VIs for Run-time Distribution.
5) If you are using TestStand 2.0 select \Examples\AccessingArrays\UsingLabVIEW\AccessingArrays.seq as the file from which the VIs should be assembled.
6) Set the target directory to be something distinct like C:\temp\AssblVIs.
7) If you are using TestStand 2.0 skip adding Dynamic VIs
8) Save with or without diagrams. Its your choice.
Change Search Directories
Once the VIs are assembled successfully, you must add the new target directory to the TS search directories.
1) In the sequence editor select Configure>>Search Directories.
2) Add your target search directory (e.g. C:\temp\AssblVIs) to the search directories.
3) Close the Edit Search Directories dialog box.
4) Confirm that your sequence steps now reference the assembled VIs. Right click on a step in the sequence and select Specify Module.
5) The dialog should show that the code module is found in the target directory (e.g. C:\temp\AssblVIs) that you just added to the search directories.
6) Run the sequence. This is the initial test to see if the VIs are assembled properly.
Switch the LV Adapter to use the TestStandLVRTS server or TestStandLVGUIRTS
1) In the sequence editor select Configure>>Adpaters.
2) In the Configurable Adapters control select the LabVIEW Standard Prototype Adapter and then click the Configure button.
3a) If you are not using the LV operator interface then switch the ActiveX server to TestStandLVRTS.
3b)If you are using the LV operator interface then switch the ActiveX server to TestStandLVGUIRTS.
4) Close the adapter configuration dialog boxes. You will get a couple of questions boxes. Just click OK each time.
5) Now run your sequence. If successful you are no longer using the LV development environment to run your VIs. This shows that the VIs were assembled correctly, the LV ActiveX server is working properly and that the search directories are configured properly.
You can now try and run the sequence using your operator interface on you development computer. If this test works it means that you have also confirmed that your operator interface is working correctly with all the other components. Now it is just a matter of moving all the component correctly to the target machine.
Distributing Components
-To distribute your operator interface use the distribution tool of the application development environment (ADE) in which you built your operator interface.
-To distribute the TS engine using the Run Engine Installation Wizard tool. This tool is typically not used for distributing your sequences and VIs, which you will probably distribute more frequently than the TS engine. It does distribute and register your LV run-time server (if you are using one) as long as you have stored it in \Components\User\RuntimeServers. It also distributes other TS components that you have stored under the directory \Components\User\.
-You can use whatever distribution system you like to distribute your VIs and sequence files (e.g. ZIP and network transfer are popular) . Ensure that you distribute the assembled VIs and not the development VIs. Also ensure that the location of the VIs on the target machine is one of the TS search directories.
Hope this helps.
Regards,
Kitt
=========================================
Title:
Overview of Distributing TestStand when your Sequences use the LV Standard Prototype Adapter
The general outline of the components to be distributed and the actions to take are followed by a more detailed description.
Components that need to be distributed:
TS engine
Operator interface
LabVIEW executable that will act as a LabVIEW ActiveX automation server (If the operator interfaces is written in LabVIEW, it can function as the LabVIEW ActiveX automation server.).
LabVIEW run-time engine
LabVIEW test VIs
Test sequence files
Actions before distributing:
It is recommended that you test the distribution components on the development machine before you distribute them to your target machine. In this manner you can more easily debug errors that you may encounter
Create the executable that will serve as your LabVIEW ActiveX server on the target machine (components 2 or 3 above).
Assemble the test VIs for distribution.
Update the TestStand search directories so that the sequences reference the assembled VIs.
Configure the LabVIEW Standard Prototype Adapter to use the LabVIEW ActiveX server that you will install on the target machine.
Test the distribution components on the development machine.
Enter section headings, separating each section with a line break:
TS Engine Component
Operator Interface Component
LabVIEW ActiveX Server
Configuring the LabVIEW Standard Prototype Adapter
LabVIEW Run-time Engine Component
Assembling your Test VIs for Distribution
Note
TS Engine Component
With any TestStand distribution you must install the TestStand runtime engine on the target machine. The Run Engine Installation Wizard tool, found under Tools menu of the Sequence Editor, facilitates this process. The wizard tool will create two files, SetupTSEngine.exe and TSEngine.cab. Move the two files to your target machine and run SetupTSEngine.exe to install the TestStand engine.
These installation files include the current configuration settings that exist in the Sequence Editor at the time the tool is invoked. It also includes all process models, TestStand types and step type modules. If you have customized components of TestStand and saved them under the directory TestStand\Components\User, then the components will also be included with the engine installation.
You must purchase at least a base deployment or debug deployment license for each machine on which you install the TestStand engine.
Operator Interface Component
You will also need to install an operator interface executable on the target machine. This program acts as a client to the TS runtime engine, controlling the execution of sequences and displaying their progress. TestStand ships with several versions of TestStand operator interfaces, which are written in different application development environments (ADE). For distributing the operator interface executable, refer to the application development environment in which it was created.
LabVIEW ActiveX Server
You must have a LabVIEW ActiveX server on the target machine. TestStand uses the LabVIEW ActiveX server to run VIs using either the LabVIEW development environment or the LabVIEW runtime engine. The LabVIEW ActiveX server is provided by either LabVIEW development environment or by any LabVIEW executable that has been built with �Enable ActiveX Server� selected. This setting can be accessed in the LabVIEW Application Builder during the build process. When this preference is enabled, you must enter a server name. You will use the server name to configure the LabVIEW Standard Prototype adapter in TestStand.
If your operator interface is written in LabVIEW, then it can act as the LabVIEW ActiveX server on your target machine. TestStand ships with two operator interfaces written in LabVIEW. The standard LabVIEW operator interface is located in TestStand\OperatorInterfaces\NI\LV, while a simplified version is located in TestStand\Examples\OperatorInterfaces\Simple LV. LabVIEW buildscripts are provided for these applications to facilitate building an operator interface in the latest version of LabVIEW. The settings of these buildscripts are such that the applications are LabVIEW ActiveX servers with the server names of TestStandLVGUIRTS for the standard operator interface, and TestStandSimpleLVGUIRTS for the simple operator interface. The applications register the servers the first time they are executed. If you want to manually register or unregister one of the servers, you can invoke the executable with the /RegServer and /UnregServer command-line arguments respectively.
If your operator interface is programmed in a language other than LabVIEW, then you will need a separate LabVIEW executable to provide the LabVIEW ActiveX server on your target machine. For this purpose, TestStand ships with a LabVIEW run-time server application located in TestStand\Components\NI\RuntimeServers\LabVIEW. A LabVIEW buildscript is provided for this application to facilitate building a run-time server in the latest version of LabVIEW. The settings of this buildscript are such that the application is a LabVIEW ActiveX server with the server name of TestStandLVRTS.
Note: When an ActiveX executable server is accessed, the executable is launched automatically if it is not already executing.
Configuring the LabVIEW Standard Prototype Adapter
When TestStand runs a VI using the LabVIEW Standard Prototype adapter, it does so using a LabVIEW ActiveX server. By default the adapter is configured to use the �LabVIEW� server, which is provided by the LabVIEW development environment. If you do not have the LabVIEW development environment on your target machine then you must configure the LabVIEW Standard Prototype adapter within TestStand to use a different server (e.g. TestStandLVGUIRTS, TestStandLVRTS, or TestStandSimpleLVGUIRTS).
To configure your LabVIEW Standard Prototype adapter, select Configure>>Adapters from the menu. In the Adapter Configuration dialog box that appears, select the LabVIEW Standard Prototype Adapter in the Configurable Adapters section. Click the Configure button. You can select or type a server name in the Select or Type Which LabVIEW ActiveX Server to User control. If your server name is not in the list you will need to type it.
As explained in the LabVIEW ActiveX Server section above, TestStand ships with LabVIEW buildscripts to build a LabVIEW operator interface and a LabVIEW run-time server application. These applications are LabVIEW ActiveX servers with server names TestStandLVGUIRTS and TestStandLVGRTS, respectively. You can configure you LabVIEW Standard Prototype adapter to use one of these servers.
LabVIEW Run-time Engine Component
If any of your sequence steps use the LabVIEW adapter or if your operator interface is written in LabVIEW, then you must install the LabVIEW runtime engine on the target machine. It is important that your LabVIEW run-time engine is the same version as the VIs that TestStand executes.
You can find installation files for the LABVIEW 5.1 run-time engine in the LabVIEW installation directory, Labview\APPLIBS\installs\RunTime. In addition, you can choose to automatically distribute and install the LabVIEW run-time engine with the distribution of a LabVIEW executable. Refer to LabVIEW documentation.
Assembling your Test VIs for Distribution
After distributing TestStand, you must ensure that your sequences are able to locate the VIs they call, and the VIs must be able to locate their required resources.
One common mistake is to simply copy the original VIs from the development machine to the target machine. Once you have configured your LabVIEW Standard Prototype adapter to use a LabVIEW ActiveX server other than LabVIEW, your sequence will not be able to execute your original test VIs that your sequences call.
TestStand provides the Assemble Test VIs for Distribution tool, which gathers test VIs and their required resources, and places them in a common location for distribution. You can then modify your TestStand search directories so that your sequences reference the assembled VIs. These topics are covered in the NIDZ document Distributing LabVIEW Test VIs.
Links: See Distributing LabVIEW Test VIs below
Note
Remember to test your distribution components on your TestStand development system before distributing TestStand. If the execution does not work on the development system it is not going to work on your target machine. On your development machine you have more ability to debug problems you may encounter.
Note: One common problem of testing distribution components on your TestStand development system is that your sequences reference the original Test VIs instead of the assembled test VIs. Refer to the NIDZ document Distributing LabVIEW Test VIs for assistance.
Once the components work on your development machine, you are ready to install them on your target machine. The order in which you install these components on the target machine is irrelevant.
==============================================

A more successful experiment in creating compositable user interfaces for Config Dialogs

A couple weeks ago I posted an experiment in creating compositable user interfaces using transparent subpanels. The approach might best be described as, "It at least was notable for being novel."
Today, I'm posting another attempt, this one along more traditional lines, and far more successful. Particularly notable: this one can do all the arbitrary composition of the last one AND it solves the TAB order problem.
This solution uses a picture control and renders N copies of a control. When the user tabs to a control or moves the mouse over the control, a real control slides into that position to be able to catch the events (update mouse over draw state, highlight for keyboard focus, handle typing, etc). When the Value Change occurs, a master array of data is updated and the picture control is updated.
This is something that has been attempted in various forms in the past, but there are two aspects of this particular implementation that make it nice:
its programmatic interface for specifying the behavior of the various objects should make it fairly easy for a user of the framework to programmatically generate their dialogs
it handles the TAB problem without flickering, something I haven't seen in other attemps
This idea spawns out of conversation about the previous experiment -- thanks to those of you who posted on various forums, e-mailed me, or, in a couple cases, showed up at my desk. That last one is not something I'm encouraging unless you work at NI... just saying. :-)
Now, this experiement has already yeilded some interesting conversation. We note that as long as controls are instantiated independent of each other -- that is, no property of one control depends upon the property of another control -- this dialog system scales nicely. But in this experiment, I implemented Radio Buttons, which interact with each other -- when one is set True, the others go False. As soon as controls start interacting with each other (such as graying out one control when a checkbox is toggled, or having expandable sections, or really complex cases like updating a graph as some options change, like happens in some Express VI config dialogs) then we start needing ways to refer to the other controls. This rapidly moves us in one of two directions: naming controls or creating references. The naming approach is definitely my preference as it fits better with dataflow and I can do some interesting effects with breaking apart some of the tree. But all of this quickly starts sounding like "Please implement a XAML parser in LabVIEW." For those of you unfamiliar with XAML, in the world of UI design, it might very well be the coolest thing since sliced bread. A XAML string would indeed fit with dataflow, and we could start building that up. I hesitate to head down this road for two reasons. One, as many have noted, there's really not a good XML parsing library written in LabVIEW that can give me a useful DOM tree. Two, that's a huge project and my gut sense is that you'd have to complete a fairly large chunk of it before you'd start seeing any return on investment. But it is worth thinking about -- I might be wrong. Wouldn't be the first time. This code that I've posted today can at least get you started on the generation side if one of you decides to become industrious.
I'm turning my attention away from this project for now... coding in G is lots of fun, and I wish I could spend more days doing it, but this has been a side project and it's time to get back to my assigned projects in text programming. Building a powerful platform for automatic UI generation in LabVIEW would be really useful -- I see lots of requests for this sort of thing, and other languages are pulling ahead of us in this domain.
[UPDATE 5/17/2012 - There is an improved version.]
Solved!
Go to Solution.
Attachments:
ConfighThroughCtrlCreation.zip ‏558 KB

Elijah K wrote:
Thanks for posting this Aristos. I would normally be one of those to go bug you at your desk, but in case I'm not the only one with this question... which particular flickering problem are you referring to? The act of switching tabs? In all honesty, I've never noticed...
When you move controls around on the screen, normally you try to Defer Panel Updates while you do that. But Defer Panel Updates has an effect on control's abilities to catch certain mouse clicks, so when you're trying to move a control to catch the mouse, you have to work a lot without Defer Panel Updates, so if you're adjusting captions, etc, to match the new location, you can see flicker as properties adjust. You can move the control off-screen, as long as you have already updated the picture control to reflect the changes. It took a while to catch all the ways that the flickering can crop up. I think I got 'em all.
Attached are the VIs saved for LV 2009. Actually, they're saved for LV 8.6, but it doesn't work in 8.6 because of a bug in the picture control that existed back then.
Attachments:
ComposableUI_LV2009.zip ‏391 KB

What is the best way to get data to a user interface?

Hi,
I'm using labview 6i. I have an application with a handful of "core" vi's that actually run my application, doing the data acquisition, analysis, and control. I am currently using these same vi's for my user interface. I also have a number of vi's that contain menu's for configuring the "core" vi's. My questions is, what is the best way to seperate the "core" vi's from the user interface vi's. Global's, data socket, control references, others?
Thanks for the help.

Hi Sal,
I have been a strong advocate of control refnums ever since LV 6i hit the streets. I recomend you look into using them to provide this conectivity.
You could accomplish this by using a variation on the following.
In your UI, create refnums for each of the controls or indicators that must be monitored or updated. Pass the appropriate refnums to each of the "core.i's" at program init time. Inside each of the core.vi's, use property nodes to read the control's values when appropriate and similarly for display purposes. (Note: Not all boolean mechanical actions are compatible with this technique. In those case you will have to explicitly write false values after find the control to be true or vise versa).
By using this technique, you can keep the UI diagrams clea
n. Depending on your app. the UI diagram could consist of the init's I mentioned above, and a while loop that watches if it's time to exit.
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

This advertised application will not be installed because it might be unsafe. Contact your administrator to change the installation user interface option of the package to basic.

Hi there,
I was wondering whether anyone could tell me which feature in Windows 7 produces this message "This advertised application will not be installed because it might be unsafe. Contact your administrator to change the installation user interface option of
the package to basic." and whether it can be turned off in Windows to prevent this message from appearing when installing certain programs that aren't WHQL certified. At first I thought it was the UAC control that generated this message but found out
that it wasn't and then thought it was the DEP control and found out that it wasn't this either. I'm only seem to be getting this message when installing FileDirector Component Service Version 3 on a few of our workstations which is an add-on that allows file
integration with Office and is part of FileDirector WinClient Version 3.
Your help would be much appreciated.
Many thanks,
RocknRollTim
P.S. I know of a way to bypass this message but would ideally not like to have the feature turned on and for the message not to be appear for non WHQL certified program installations in order to make non WHQL certified program installations in the future much
easier, more simpler and straightforward to carry out. I was redirected by a moderator off the Microsoft Community Forum.

Hi,
You can try following options to disable this prompt, but we don't recommend you to do so since this feature helps you to protect your computer.
Option 1: Run command as admin:
bcdedit -set loadoptions DDISABLE_INTEGRITY_CHECKS
bcdedit -set TESTSIGNING ON
Restart your computer to apply changes.
Option 2: Disable in GPO:
1.Type gpedit.msc in the Run dialog and press Enter.
2.In the Group Policy Editor, navigate to User Configuration → Administrative Templates → System → Driver Installation.
3.Double-click on Code signing for device drivers in the right-side pane as shown above.
4.In the windows that opens, choose Enabled. In the Options, choose Ignore as shown. Then click on the OK button to save the settings.
Restart your computer to apply changes.
Kate Li
TechNet Community Support
Unmarked as Answer based on OP's request.
https://social.technet.microsoft.com/Forums/en-US/35ab1279-c3a1-46be-9f7d-45e8606c1410/this-advertised-application-will-not-be-installed-because-it-might-be-unsafe-contact-your?forum=w7itproappcompat
Arnav Sharma | http://arnavsharma.net/ Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading
the thread.

'Design Patterns' for Application User Interfaces

I'm currently trying to unstick an architectural mess centred around a relatively simple user interface. The problem is thus:
The application has a number of toolbar buttons and menus, some of which require a specific frame or class of frame to be enabled. Some conditions are quite simple, others more complicated.
(Without going into any more detail, it should be possible to appreciate that this is a fairly common problem.)
For this application, I've created a large listener that accepts events from all over the program, converting them into state changes for UI controls. It feels messy, and (although it isn't finished) I suspect it'll be rather fragile.
JBuilder 4 does it by constant querying of application state - but this results in excessive CPU usage and apparant lag.
TogetherJ does it for menus by checking state immediately before showing the menu. This seemed like a good plan, but it's unsuitable for the Action/Button/MenuItem lashup I like to use.
My question is this:
In your opinion, how should an application be structured to reliably maintain the correct UI state at all times?

Check out the mediator pattern. It is pretty close to what you are describing, maybe the details you dig up on it will give you some new ideas?

How can I improve the response time of the user interface?

I'm after some tips on how to improve the response time to mouse clicks on a VI front panel.
I have data acquistion application which used to run fine, but after spending a couple of weeks making a whole bunch of changes to it I find that the user interface has become a bit sluggish.
My main GUI VI has a while loop running 16 times a second, updating some waveform charts and polling about a dozen buttons on the front panel.
There is sometimes a delay (variable, but up to 2 seconds sometimes) from when I click on a button to when it becomes depressed. I have wired the iteration terminal of the while loop to an indicator on the front panel and can see that the while loop is ticking over during the delayed response to the mouse click, so I know that the problem is not that the whole program is running slow, just the response to mouse clicks.
Also, just for debugging purposes, I have indicators of the iterations of all the main while loops in my program on the front panel, so I can see that there are no loops running abnormally fast either.
One thing I've tried is to turn off multi-threading, and this does seem to work - the response to mouse clicks is much faster. However, it has the side effect of making the main GUI while loop run less evenly. I was trying to get a fairly smooth waveform scrolling across the screen, and when multi-threading is off it gets a bit jerky.
Any other suggestion welcome..
(I am using LabVIEW 7.1, Windows 2000).
Regards,
Mark.

Hi Altenbach,
Thanks for your reply. In answer to your questions:
I am doing both DAQ board and serial data acquisition. I am using NIDAQ traditional for the DAQ board, and VISA for the serial. I have other similar versions of this program that do only DAQ board, or only serial, and these work fine. It was only when I combined them both into the same program that I ran into problems.
The multiple while loops are actually in separate VIs. I have one VI that acquires data from the DAQ card, another VI that acquires data from the serial port, another VI that processes the data and saves to file, and another VI, the GUI VI, that displays the data in graphs and charts. The data is transferred betwen the VIs via LV2 globals.
The GUI VI is a bit more complicated than I first mentioned. It has tab control, with 4 waveform charts on one page, 4 waveform graphs on another page, and 3 waveform graphs on another page. The charts have a history length of 2560, and 16 data points are added 16 times a second. The wavefom graphs are only updated once per minute.
I don't use the value property at all, but I do use lots of property nodes for changing the properties of the graphs and charts e.g. changing plot colours, Y scale range etc. There is only one local variable (for the Tab control). All the graphs and charts have data wired directly to their terminals.
I haven't done any profiling yet.
I am building arrays in uninitialised shift registers, but this is all well under control. As the experiement goes on, more data is collected and stored, and so the memory usage does gradually increase, but only to the extent that I would expect.
The CPU usage is 100%, but I thought this was always the case when using NIDAQ with DAQ cards. Or am I wrong about this? (As a side note, I am using NIDAQ traditional, but would NIDAQmx be better?)
Execution priority of the GUI vi (and all the other VIs for that matter) is set to normal.
The program is a bit large to post here, and I'm not sure if my company would be happy for me to publicise it anyway, so I suspect that this is turning into one of those questions that are going to be impossible to answer.
Just as a more general question, why would turning off multi-threading improve the user interface response?
Thanks,
Mark.

Dynamic programming user interface question...

Similar Messages

Maybe you are looking for