I've been trying to access cluster variables. Recently I learned that you cant do so using .NET Network Shared Variables and I found that people usually do this via AcitveX.
Using ActiveX I am able to run any VI I want and change the values but most of the VIs that I am trying to access have UI Loops and Consumer Loops. Changing the value of a control manually, fires an event that is detected and leads to certain actions that I am interested in. After reading some old KBs I found out that with ActiveX one can't do that.
Is it the same in LabView 2015? In some forums people discussed creating a VI within the ActiveX program that fires the user events, a sort of a layer. Can someone share examples of such VIs? Are there any other work arounds?
You can programmatic fire a signal event by using the property node -> value(Signaling)
Right click on the control in the block diagram, this can be found under: Create -> Property Node -> Value(Signaling).
Any value written to this node will generate a signal event for this specific control. You don't specifically need ActiveX to generate these events.
You can fire events with property nodes (as already explained by #D.J. Klomp)
You can capture and handle change events with event structures
This can be done even for single controls inside a cluster.
Related
In my program, the creation of the main form is slow : I have identified that it hangs for around two seconds just before the form's OnCreate event is called. So I suspect this is happening while the components are created.
Since this form has several frames, I wonder if there is a way to "profile" component creation in order to see where I can improve. I suspect the lag comes from the opening of a database table that should not be open at that time (rather later, after some filtering is in place).
If there is a way get an event triggered before/after each component creation, I could do the profiling myself (with codesite for example).
Or maybe it is possible to do the component creation manually ?
Here is a quick and dirty way to work out where the delay is:
Take a copy of the Classes unit source code and place it in your project's source folder. This will ensure that this unit is compiled into your program rather than the one supplied with Delphi.
Modify the code in the constructor of TComponent. All streamed components pass through here during creation. Add code to log the class name, e.g. using CodeSite for instance.
Run your program, and then inspect the resulting log to identify the delay.
If you have many components then just knowing the class might not narrow it down. You might inject logging code into TComponent.SetName instead which will let you log the component's name. However, the basic idea is simple enough, and you should be able to apply it to your setting in order to find out the information you need.
I know how to force forms to appear on the same monitor as the running application, but I do not see how to ask the Help or the Printer Setup dialogs to display on the same monitor. The Help displays where it displayed last time, but we want it to show up on the application monitor. The Printer Setup dialog always seems to appear on the primary monitor
Passing the parent form's Handle to TPrinterSetupDialog.Execute seems to do the trick.
if PrinterSetupDialog1.Execute(Self.Handle) then
//
Using Delphi 7 (where the TPrinterSetupDialog.Execute does not accept a parameter), you have two choices.
The easiest would be to create your own descendant of TPrinterSetupDialog. Execute is virtual in TCommonDialog, the ancestor of TPrinterSetupDialog, where it is overridden. You could override it in your own descendant, use the code in the TPrinterSetupDialog as a basis for your own Execute override, adding overload as well. Your overloaded Execute would accept a ParentHandle: HWND parameter, and set the PrintDlgRec.hWndOwner to that provided window handle.
I thought about trying to write this for you (or at least get it started), but there are additional things you'd have to copy from the Dialogs unit (functions that are defined in the implementation section that wrap some API calls, and the callback function that's used for the dialog's message loop), and I don't have D7 available where I'm at to even try to compile it.
The other alternative (as David Heffernan mentioned in his comment below) would be to call the Windows API PrintDlgEx directly yourself. This is discussed in MSDN, in the Print Dialog Box (Windows) topic. Once again, I don't have D7 available, so I can't really give you an example of using it from Delphi. (I checked, and don't have one tucked away anywhere.)
I'm not sure you can set the help window's position; I think that's done automatically by Windows based on the user's prior use. (I haven't been able to so so, anyway.)
I've started to look at using Omnithread to improve my Delphi Application using multithreading. Creating one or more worker tasks are well covered by the documentation so that long actions that I invoke from button clicks can be replaced by this demo code (Async, CreateTask etc). Where I am having difficulty though is in how to replace my most 'messy' code which operates as follows.
I have a concept of a single class instance that corresponds to a hardware module. The class publishes one or more properties that expose current values and settings for the hardware. Properties might be read only or read / write. For each of these class instances there can be from zero to several display forms visible. A display form has a TTimer and a built list of the aformentioned published properties. This list is iterated to match up suitably named controls such as labels or edit controls and an RTTI mechanism is used to get and set values between the control and its property. The result is a form which provides a nice UI on to the actual hardware module with the side effect than multiple forms can be open, modifying data on one of them causes the others to show that data shortly after. This property monitoring is performed by the TTimer ticking at 300 ms intervals. Each tick causes it to scan through all properties of the class and to refresh the matching control on its form. The timer runs for the lifetime of the open form. Forms are created when needed and then freed (this has the useful performance optimisation that with no forms open to inspect the hardware, the Application must run as fast as possible because no monitoring tasks can be running).
Is there a better way of using threading to access my published properties, rather than using a TTimer in the UI thread? Or would synchronisation issues outweigh any advantages? If threading is useful, how would one create a repeating task such as to emulate the ticking timer?
I haven't done any coding of this kind and would like some pointers how to start. The service will eventually do several things and perhaps someone has already thought of it made it happen.
The big picture is this: Detect if a PowerPoint presentation has been updated on the server. If it has extract the slides and save them as individual jpegs then upload them to a specific image list in SharePoint. All this has to happen without human intervention.
I assume this would be a window service project, right? Then a file stream property that with some property that deals with changes in the file?
As far as dissecting a .pptx/.ppsx files and get the slides converted, it there a "api" or some dll class?
What about uploading files to a library list on SharePoint automatically?
Thanks,
Risho
I've done this in Topshelf http://topshelf-project.com/, a windows service host for .NET.
https://github.com/Topshelf/Topshelf/blob/master/src/Topshelf/FileSystem/FileSystemEventProducer.cs
Since Windows has an event pump issue if events take too long, we also implemented polling on top of this since the FileSystemWatcher gets disconnected during those times.
https://github.com/Topshelf/Topshelf/blob/master/src/Topshelf/FileSystem/PollingFileSystemEventProducer.cs
Now, these producers are supposed to be tied to actors so they might seem a bit overly complicated for just checking on file system events. It's up to use if that model is useful or just the core part. Remember that you can often receive events even if the file is locked or not done yet, so handle those exceptions.
SharePoint has what is called a timer service for just these types of situations. Andrew Connell has an article regarding creating your own timer jobs.
http://www.andrewconnell.com/blog/archive/2007/01/10/5704.aspx
I'm developing a application in Lazarus, that need to check if there is a new version of a XML file on every Form_Create.
How can I do this?
I have used the synapse library in the past to do this kind of processing. Basically include httpsend in your uses clause, and then call httpgetbinary(url,xmlstream) to retrieve a stream containing the resource. I wouldn't do this in the OnCreate though, since it can take some time to pull the resource. Your better served by placing this in another thread that can make a synchronize call back to the form to enable updates, or set an application flag. This is similar to how the Chrome browser displays updates on the about page, a thread is launched when the form is displayed to check to see if there are updates, and when the thread completes it updates the GUI...this allows other tasks to occur (such as a small animation, or the ability for the user to close the dialog).
Synapse is not a visual component library, it is a library of blocking functions that wrap around most of the common internet protocols.
You'll need to read up on FPC Networking, lNet looks especially useful for this task.