Jump to content

bjustice

Members
  • Posts

    159
  • Joined

  • Last visited

  • Days Won

    11

Posts posted by bjustice

  1. On 7/22/2020 at 6:00 AM, hooovahh said:

    I also was a bit frustrated by this some times.  So attached is a demo of some panel movement code.  It has a few main functions. 

    The first is sometimes I'd have a dialog I wanted to pop up, but I wanted it to be centered on whatever monitor the mouse was on.  My thought was that this was the monitor the user was using, and they probably just clicked something, so put it there. 

    I also had times that I would pop up a dialog under the mouse and so I wanted the panel to be centered on the mouse as best it can, but stay on the same monitor.  This doesn't always work well with taskbars that can be hidden, and size and position not being consistent but it mostly works.

    And lastly I sometimes had a need to set a panel to maximize on a specific monitor.  We typically would have 2 or 3 set side by side in the system.  So this VI can set a panel to maximize on the "Primary", "Left", "Right", "Second from Left" or a few others.

    As you noticed this won't fix LabVIEW native dialogs, and any solution I can think of for those will be a bit hacky.

    Panel Movement Center Maximize Demo.zip 97.17 kB · 35 downloads

    @hooovahh I find myself using this code for so many things that I do.

    I feel like it makes sense to build this into a little VIPM package.  (Especially since I'm about to release a package to VIPM that uses this code.)

    If I were to turn this into a VIP, is there an appropriate way for me to credit you?

  2. Oh wow, Zou is right, you can copy item parts to clipboard, and then paste these item parts over other item parts.  This seems to carry more than just a static image - this carries the item part type and properties.

    I'll keep poking at it with this new information, thanks.

     I really wish LabVIEW had a more full-featured custom control editor.

  3. Here, I made a demo illustrating what I'm trying to accomplish.  It's kinda cool:

    image.png.2166fc8e75c0aa4aa7f62550477ffaa9.png

    Note how I've been able to create a button using custom (rectangular) images, but I still have an oval click area.  That way, clicking the corners does nothing.  Which is good!

    The only thing missing: This demo button only has 4 item-parts.  I really wish I could get a control with this behavior, but also with 6 item parts.  (So that I can import custom images for the mouse over states.)

    demo round custom button.vi

  4. The DMC GUI Suite has buttons that have:

    1) "Boolean Button" --> 6 part items

    2) "Boolean Light" --> 4 part items

    I can't seem to figure out how they were able to make this combination, because I can't find any control on the native palette with these item parts.

    image.png.38496159954190ffca46f847fbce7160.png

     

    For what it's worth, I'm really hoping to be able to create a custom button that has a circular click-radius, but also allows for me to important custom pictures for all 6 boolean states.

    Importing custom pictures into a NxG or System button control is easy to get work.

    What's slightly more difficult is that I'm hoping to be able to use a transparent "Boolean glyph" item part as the thing that dictates the click-bounds.  That way the button doesn't appear as a circular image, with a square click bound.

    I recognize that there are lots of workarounds here, but I'm sorta just hoping that maybe there is some way to create the control with the item parts that I desire.  This DMC button is sooooo close to being exactly what I need.

  5. Request: A button that has the "parts":

    1) Boolean Button --> round shape with 6 part items

    2) Boolean Glyph --> must also have 6 part items

     

    For example, the standard LED is close to what I want, but it only has 4 item states, so there is no 5/6th states for hover-over value.

    image.png.ed5be03ce0aaf843f020720268f7bcf5.png

     

    Taking this a bit further:
    The NxG buttons all have 6 item parts.  However, the NxG buttons don't have a "Boolean Glyph" item part.

    So, naturally, I would like to understand: am I able to "import" the "boolean glyph" item part from the LED into a NxG button control?

     

    All of the forum posts that I've found thus far only document how to add decorations, or how to modify existing item parts in a control.  There is no documentation on how to actually add item parts to a control... which I suspect is sorta getting into a layer of code not exposed to me.

  6. Yeah, Neil understands me here

    A shortcut cannot be a blank string.  So, I would expect a blank string, which is also the default value of the input, to yield a no-op.

    I created my own abstraction layer to sit on to of the low level menu API.  My abstraction layer is used by both by my main menu as well as by control references.  So, this behavior forced me to write a comical piece of code where I case structure 2 copies of this NI primitive, where 1 case does not wire up the shortcut input.

  7. Ok, I found something.  And it really feels like this disobeys the Laws of LabVIEW physics.

    image.png.dd4c83da587ac6dc4614fbd2484153f6.png

    image.png.68c5a8e6110739db53b47c2798f10121.png

     

    It would be my expectation as a LabVIEW developer that both the top and bottom code should execute exactly the same.  (The constant short-cut cluster wired into the "Set Menu Item Info" function is the default value of the cluster, created by right-click + create constant from the terminal of the VI.)  I would expect the default/blank value to yield a no-op.

    However, if you run the attached VI, you will find that the top screenshot produces an error.  The bottom does not.

    button right click menus are not allowed to have shortcuts.  And that's fine.  But I can't figure out how to wire a cluster to this NI primitive in a way that let's me communicate a desired no-op behavior.

    I'm scratching my head trying to determine how this even works.  Does this mean that the NI primitive is able to have code that discerns and reacts to whether or not an input terminal is wired?  It seems like that breaks LabVIEW paradigm.

    Ok, that's all.  Saw something weird and wanted to share.

    Menu example.vi

  8. BlueSerialization is currently LabVIEW 2020.

    hmm... okay.  How bulletproof do you think your VI might be?  Would LabVIEW ever be "smart" enough to not load a classes' *.ctl file into memory if it was blank or something like that?  Or perhaps drop it from a build if it were blank?

    If you think this is pretty bulletproof, I'll just use this and push a patch to the BlueSerialization library.

    I am already cacheing the results, so speed is probably not a huge issue.

  9. I ran into a situation where I need to return the class hierarchy of an object as a concrete object array.  (If you are curious, this is used in the BlueSerialization toolkit)

    The following code snippet demonstrates how I accomplished this.
    Unfortunately, I just discovered that this algorithm doesn't work if a class also inherits from an interface class.  (My algorithm here assumes that a class can only inherit from 1 other class.)

    Naturally, my immediate question is this:

    Is there a graceful NI primitive or mechanism for determining if a given object is an interface class or a concrete class?

    If yes, then I could just filter out interface classes in my code here and move on with life.

    image.png.7dc7c473f113e271b24d40e42cd4be86.png

     

    I did find the "Get LabVIEW Class Parent and Member VI information VI.  But, I can't get this VI to work recursively.  On the 2nd loop iteration, this NI primitive returns that results for a base LabVIEW object even though the wire probe shows this as not being a base LabVIEW object.

    image.png.57003127745ac439b88bd8a1437a97b0.png

     

    Get Class Hierarchy.vi

  10. 2 hours ago, drjdpowell said:

    Does a Property Node, with multiple Properties set, execute as a single action, without a parallel Property Node executing in the middle?   If so, then resetting the Active Plot in the second Property Node in the bottom loop would prevent any race condition.

    I would really like to know the answer to this question.  I would expect the answer to be "yes" since property nodes all run in the UI thread

  11. Another network question:

    Do I have to implement reconnect logic when using UDP?

    More pointedly:

    If I successfully open a UDP port, then will this UDP connection ID ever become invalid or closed somehow in a way that would force me to close it and then reopen it to reestablish communications?

    Example: TCP requires proper handling of reconnect logic.  When the client or server closes the TCP connection, then the connection is closed on both ends.

    image.png.db3bdce66bc6aa00d83ddeab67e2d9f4.png

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.