Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Determining Visible/Hidden Status of Open Windows
56 views
Skip to first unread message
jahn
Apr 26, 2012, 2:30:56 AM4/26/12
to
Hi, group -
I've got a question about identifying whether a window is visible or
hidden. On a Mac using FM 11 Advanced, I have a database that opens
three windows offscreen at startup and names them "Customers,"
"Vendors" and "Prospects." Two of the windows get hidden and the
third – whichever the user designates as his default table – is
brought onscreen as the active window. The status area is locked down
and standard operations are done through custom menus, scripting and a
button bar, allowing full developer control of window behavior.
I want users to be able to click tabs at the top of the screen to
navigate to the other windows. For example, if the user has Prospects
open and clicks the Vendors tab, the Prospects window gets hidden and
the Vendors window gets brought to the fore. This is no problem. I
also want users to be able to shift-click the tabs in order to open
windows next to each other, so they can have, say, Vendors and
Prospects side-by-side if they want. This is also no problem. Then
when a user closes the second or third window, I want to hide it
rather than actually close it. Again: custom menus and scripting – no
problem.
But then things start to give me trouble. If a user has two windows
showing – say Prospects and Vendors – I want the simple click to
select the clicked window and leave the other one visible, rather than
hiding it. This means that FileMaker has to be able to identify
whether a non-selected window is visible or hidden. I also want all
windows to close if the user closes the last visible window – which
again requires FM to identify whether non-selected windows are visible
or hidden.
I haven't worked that much with hidden and visible windows and don't
see how I can identify the status of a window that's not selected.
The Get(WindowVisible) function seems to only provide information
about the current window, which means if I want to know about a
different window, I have to select it – which of course automatically
makes it visible, at which point I can't find out whether it was
visible or hidden before I selected it.
So the question is: Is there a way to find out the visible/hidden
status of all windows at any given moment? What do you think?
Thanks in advance for any help.
Best,
-J.
I've got a question about identifying whether a window is visible or
hidden. On a Mac using FM 11 Advanced, I have a database that opens
three windows offscreen at startup and names them "Customers,"
"Vendors" and "Prospects." Two of the windows get hidden and the
third – whichever the user designates as his default table – is
brought onscreen as the active window. The status area is locked down
and standard operations are done through custom menus, scripting and a
button bar, allowing full developer control of window behavior.
I want users to be able to click tabs at the top of the screen to
navigate to the other windows. For example, if the user has Prospects
open and clicks the Vendors tab, the Prospects window gets hidden and
the Vendors window gets brought to the fore. This is no problem. I
also want users to be able to shift-click the tabs in order to open
windows next to each other, so they can have, say, Vendors and
Prospects side-by-side if they want. This is also no problem. Then
when a user closes the second or third window, I want to hide it
rather than actually close it. Again: custom menus and scripting – no
problem.
But then things start to give me trouble. If a user has two windows
showing – say Prospects and Vendors – I want the simple click to
select the clicked window and leave the other one visible, rather than
hiding it. This means that FileMaker has to be able to identify
whether a non-selected window is visible or hidden. I also want all
windows to close if the user closes the last visible window – which
again requires FM to identify whether non-selected windows are visible
or hidden.
I haven't worked that much with hidden and visible windows and don't
see how I can identify the status of a window that's not selected.
The Get(WindowVisible) function seems to only provide information
about the current window, which means if I want to know about a
different window, I have to select it – which of course automatically
makes it visible, at which point I can't find out whether it was
visible or hidden before I selected it.
So the question is: Is there a way to find out the visible/hidden
status of all windows at any given moment? What do you think?
Thanks in advance for any help.
Best,
-J.
David Stone
Apr 26, 2012, 10:15:59 AM4/26/12
to
In article
<18e761de-d174-4109...@2g2000yqk.googlegroups.com>,
different layouts for customers, vendors and prospects. That way,
a simple script using "Go To Layout" and linked to buttons lets the
user switch without you needing to worry about window status.
Even in FM 8.5, however, there are numerous options for manipulating
windows in scripts - have you looked at these? "Select Window" and
"Adjust Window" look like their options will accomplish what you need.
I haven't tested, but I suspect that if a window is hidden and you
select/adjust it, its visibility will automatically be toggled for
you.
<18e761de-d174-4109...@2g2000yqk.googlegroups.com>,
jahn <jahnbi...@yahoo.com> wrote:
> Hi, group -
>
> I've got a question about identifying whether a window is visible or
> hidden. On a Mac using FM 11 Advanced, I have a database that opens
> three windows offscreen at startup and names them "Customers,"
> "Vendors" and "Prospects." Two of the windows get hidden and the
> third – whichever the user designates as his default table – is
> brought onscreen as the active window. The status area is locked down
> and standard operations are done through custom menus, scripting and a
> button bar, allowing full developer control of window behavior.
>
> I want users to be able to click tabs at the top of the screen to
> navigate to the other windows.
I would have approached this differently, using a single window and
> Hi, group -
>
> I've got a question about identifying whether a window is visible or
> hidden. On a Mac using FM 11 Advanced, I have a database that opens
> three windows offscreen at startup and names them "Customers,"
> "Vendors" and "Prospects." Two of the windows get hidden and the
> third – whichever the user designates as his default table – is
> brought onscreen as the active window. The status area is locked down
> and standard operations are done through custom menus, scripting and a
> button bar, allowing full developer control of window behavior.
>
> I want users to be able to click tabs at the top of the screen to
> navigate to the other windows.
different layouts for customers, vendors and prospects. That way,
a simple script using "Go To Layout" and linked to buttons lets the
user switch without you needing to worry about window status.
Even in FM 8.5, however, there are numerous options for manipulating
windows in scripts - have you looked at these? "Select Window" and
"Adjust Window" look like their options will accomplish what you need.
I haven't tested, but I suspect that if a window is hidden and you
select/adjust it, its visibility will automatically be toggled for
you.
jahn
Apr 26, 2012, 1:20:27 PM4/26/12
to
Hi, David -
Thanks for the quick reply. Generally I use a single window like you
recommend, but for this database it seemed better to go with multiple
windows based on the client's workflow and the structure of the data.
There are a lot of reasons for this, and when I first started writing
my post I laid it all out in many long paragraphs, but then thought,
"Who the hell wants to read me jabbering on for many long paragraphs?"
and realized the question boiled down to basically: "How do you
determine the visibility of open windows?" So even though there are a
lot of advantages to a single window, in this case they're outweighed
by the advantages of multiple windows.
With regard to Select Window and Adjust Window: these are all useful
for manipulating windows, but they won't tell me whether a window is
visible or hidden before FM acts on a window -- and in this design,
the window's visibility status determines how it should be handled.
Basically I want to achieve three things: I want to keep different
found sets in separate windows; I want to give the user the ability to
look at those datasets simultaneously; and I want to hide extra
windows if the user only wants to look at one of them. In order to do
all three of these seamlessly, the database needs to make a decision
about what to do when a user clicks on a tab, and that decision
changes based on whether a user is looking at multiple windows or only
one.
So I think the only answer that gets me there is how to determine the
visibility of open windows, which seems like something you ought to be
able to do with a function like Get(WindowVisible) combined with a
design function like WindowNames. Except that Get(WindowVisible) only
identifies the status of the current window (not all windows), and
WindowNames only identifies which windows are open (although it does
list them in their current stacking order, with visible windows first,
minimized windows next, and hidden windows last -- getting us so close
to what we need, it's almost perverse that FM doesn't go the final
mile).
Any other ideas? I feel like I'm overlooking something simple,
because it's obviously info that FM has at its disposal, since the
WindowNames function relies on it. But I can't quite see how to crack
it open.
Thanks again.
Best,
-J.
Thanks for the quick reply. Generally I use a single window like you
recommend, but for this database it seemed better to go with multiple
windows based on the client's workflow and the structure of the data.
There are a lot of reasons for this, and when I first started writing
my post I laid it all out in many long paragraphs, but then thought,
"Who the hell wants to read me jabbering on for many long paragraphs?"
and realized the question boiled down to basically: "How do you
determine the visibility of open windows?" So even though there are a
lot of advantages to a single window, in this case they're outweighed
by the advantages of multiple windows.
With regard to Select Window and Adjust Window: these are all useful
for manipulating windows, but they won't tell me whether a window is
visible or hidden before FM acts on a window -- and in this design,
the window's visibility status determines how it should be handled.
Basically I want to achieve three things: I want to keep different
found sets in separate windows; I want to give the user the ability to
look at those datasets simultaneously; and I want to hide extra
windows if the user only wants to look at one of them. In order to do
all three of these seamlessly, the database needs to make a decision
about what to do when a user clicks on a tab, and that decision
changes based on whether a user is looking at multiple windows or only
one.
So I think the only answer that gets me there is how to determine the
visibility of open windows, which seems like something you ought to be
able to do with a function like Get(WindowVisible) combined with a
design function like WindowNames. Except that Get(WindowVisible) only
identifies the status of the current window (not all windows), and
WindowNames only identifies which windows are open (although it does
list them in their current stacking order, with visible windows first,
minimized windows next, and hidden windows last -- getting us so close
to what we need, it's almost perverse that FM doesn't go the final
mile).
Any other ideas? I feel like I'm overlooking something simple,
because it's obviously info that FM has at its disposal, since the
WindowNames function relies on it. But I can't quite see how to crack
it open.
Thanks again.
Best,
-J.
Ursus
Apr 26, 2012, 2:16:52 PM4/26/12
to
>
> So I think the only answer that gets me there is how to determine the
> visibility of open windows, which seems like something you ought to be
> able to do with a function like Get(WindowVisible) combined with a
> design function like WindowNames. Except that Get(WindowVisible) only
> identifies the status of the current window (not all windows), and
> WindowNames only identifies which windows are open (although it does
> list them in their current stacking order, with visible windows first,
> minimized windows next, and hidden windows last -- getting us so close
> to what we need, it's almost perverse that FM doesn't go the final
> mile).
>
> Any other ideas? I feel like I'm overlooking something simple,
> because it's obviously info that FM has at its disposal, since the
> WindowNames function relies on it. But I can't quite see how to crack
> it open.
>
> Thanks again.
>
> Best,
> -J.
You hide/show your windows with a script.
> So I think the only answer that gets me there is how to determine the
> visibility of open windows, which seems like something you ought to be
> able to do with a function like Get(WindowVisible) combined with a
> design function like WindowNames. Except that Get(WindowVisible) only
> identifies the status of the current window (not all windows), and
> WindowNames only identifies which windows are open (although it does
> list them in their current stacking order, with visible windows first,
> minimized windows next, and hidden windows last -- getting us so close
> to what we need, it's almost perverse that FM doesn't go the final
> mile).
>
> Any other ideas? I feel like I'm overlooking something simple,
> because it's obviously info that FM has at its disposal, since the
> WindowNames function relies on it. But I can't quite see how to crack
> it open.
>
> Thanks again.
>
> Best,
> -J.
Use a script step to keep track
Set 6 GlobalVariables storing the windowname and state like so:
Set variable $$Window1Name = "NameOfMyFirstWindow"
Set variable $$Window1State = "StateofMyFirstWindow"
etc
Keep these values uptodate when you make any changes to any window and you
can test on these values all the time
Keep Well, Ursus
David Stone
Apr 26, 2012, 2:25:53 PM4/26/12
to
In article
<a592493b-59e0-4d61...@r32g2000yqj.googlegroups.com>,
jahn <jahnbi...@yahoo.com> wrote:
> Hi, David -
[snip]
For example, one of them allows you to hide a window. I'm
assuming (because it seems reasonable) that the script would give
you a "Show" option if the window was already hidden. Failing that,
selecting a currently hidden window should automatically show it.
I don't have anything I can try these out with myself right now,
but if you haven't tested whether the existing window script
commands do what you need them to, it might be worth a few minutes
exploration!
Cheers,
<a592493b-59e0-4d61...@r32g2000yqj.googlegroups.com>,
jahn <jahnbi...@yahoo.com> wrote:
> Hi, David -
[snip]
> So I think the only answer that gets me there is how to determine the
> visibility of open windows, which seems like something you ought to be
> able to do with a function like Get(WindowVisible) combined with a
> design function like WindowNames. Except that Get(WindowVisible) only
> identifies the status of the current window (not all windows), and
> WindowNames only identifies which windows are open (although it does
> list them in their current stacking order, with visible windows first,
> minimized windows next, and hidden windows last -- getting us so close
> to what we need, it's almost perverse that FM doesn't go the final
> mile).
Did you try a quick mockup to test the existing script commands?
> visibility of open windows, which seems like something you ought to be
> able to do with a function like Get(WindowVisible) combined with a
> design function like WindowNames. Except that Get(WindowVisible) only
> identifies the status of the current window (not all windows), and
> WindowNames only identifies which windows are open (although it does
> list them in their current stacking order, with visible windows first,
> minimized windows next, and hidden windows last -- getting us so close
> to what we need, it's almost perverse that FM doesn't go the final
> mile).
For example, one of them allows you to hide a window. I'm
assuming (because it seems reasonable) that the script would give
you a "Show" option if the window was already hidden. Failing that,
selecting a currently hidden window should automatically show it.
I don't have anything I can try these out with myself right now,
but if you haven't tested whether the existing window script
commands do what you need them to, it might be worth a few minutes
exploration!
Cheers,
David Stone
Apr 26, 2012, 2:39:50 PM4/26/12
to
> With regard to Select Window and Adjust Window: these are all useful
> for manipulating windows, but they won't tell me whether a window is
> visible or hidden before FM acts on a window -- and in this design,
> the window's visibility status determines how it should be handled.
> Basically I want to achieve three things: I want to keep different
> found sets in separate windows; I want to give the user the ability to
> look at those datasets simultaneously; and I want to hide extra
> windows if the user only wants to look at one of them. In order to do
> all three of these seamlessly, the database needs to make a decision
> about what to do when a user clicks on a tab, and that decision
> changes based on whether a user is looking at multiple windows or only
> one.
Ok, I did a little quick playing.
> for manipulating windows, but they won't tell me whether a window is
> visible or hidden before FM acts on a window -- and in this design,
> the window's visibility status determines how it should be handled.
> Basically I want to achieve three things: I want to keep different
> found sets in separate windows; I want to give the user the ability to
> look at those datasets simultaneously; and I want to hide extra
> windows if the user only wants to look at one of them. In order to do
> all three of these seamlessly, the database needs to make a decision
> about what to do when a user clicks on a tab, and that decision
> changes based on whether a user is looking at multiple windows or only
> one.
You can write scripts to show (actually the option is "Restore") and
hide the window by title:
Select Window [Name: "Display"; Current file]
Adjust Window [Hide]
or
Select Window [Name: "Display"; Current file]
Adjust Window [Restore]
It doesn't matter what the current state of the window "Display" is.
That is, calling Restore on a hidden window shows it, but calling
Hide on a hidden window doesn't somehow increase its hidden-ness
(you only need to restore it once to make it visible).
Once you have your show/hide scripts for each of your three windows,
you can (a) attach them to buttons on the layout and (b) invoke them
from elsewhere. So, if the user clicks to show Window3, then Window3
becomes visible. If they do something that means Window3 should now
be hidden, then your handling of that action must invoke the relevant
script to hide Window3. The exact logic depends on what your database
does and how it handles user input and searches. In essence, though,
you do not need to have prior knowledge of a windows current state
in order to either show or hide it.
jahn
Apr 26, 2012, 4:41:37 PM4/26/12
to
Aha. Excellent idea, Ursus. That'll work. Thanks.
jahn
Apr 26, 2012, 6:40:53 PM4/26/12
to
Hi, David -
Thanks for spending time on this. You're right that the visibility
status of a window doesn't matter -- except when it does.
Unfortunately, explaining it in writing is a little cumbersome, so I
apologize in advance for that.
Here's the setup: Three windows named Customers, Vendors and
Prospects. A simple click on one of the tabs hides the current window
and makes the destination window visible in the same location and with
the same dimensions as the current window. For example, say I'm in
Customers; if I click the Vendors tab, FM will show the Vendors window
using the location and dimensions of Customers, then hide Customers.
This scenario might be called "single-window emulation." The
visibility status of any given window doesn't matter; the script works
by using the current window's name and the destination window's name.
The important thing to note in this process is that, in order to
emulate a single-window, the destination window has to be set to the
same location and dimensions as the current window. If it didn't do
that, windows would become visible wherever they were last located,
which would be pretty strange behavior from a user perspective.
Second scenario: A shift-click on one of the tabs indicates that the
user wants to see the destination table in a different window.
"Different" means different from the user's perspective, since in
actuality the tables are always being displayed in a different
window. So we might say that shift-clicking means "let me see two
windows simultaneously" (or three, or six, or however many tables the
user wants to open at the same time). So when the user shift-clicks a
tab, FM makes the destination window visible, but this time offsets it
by, say, 25 pixels, and instead of hiding the current window, leaves
it visible. For example, I'm in Customers; I shift-click the Vendors
tab. The script will display the Vendors window next to the Customers
window -- that is, make it visible in a location offset from
Customers. So far so good; the visibility status of any given window
still doesn't matter.
But then, in order to go back to Customers, the user reflexively
clicks the Customers tab in the Vendors window, even though he could
just click the Customers window with his mouse or hit Command-tilde or
whatever. There are multiple ways to get back to the Customers
window, and the one he chooses is to click the Customers tab. If the
database knew that the Customers window was visible, it would just
select Customers. But since it doesn't know that, it does what it
always does when you click a tab, which is to make the destination
window visible in the same location as the current window.
In other words, instead of just selecting the Customers window, it
yanks it out of its place and puts it where the Vendors window was
located, then hides Vendors. From a user's perspective, this is
pretty disconcerting. The database should've known that he was
looking at two windows (that is, that he had two windows visible) and
adjusted its behavior by simply selecting the Customers window instead
of moving it.
This problem is similar if he's looking at two tables -- Vendors in
the foreground and Customers in the background -- and shift-clicks the
Customers tab. Now instead of just selecting the Customers window, it
yanks it out of place and offsets it from the Vendors window. Again,
from a user's perspective disconcerting. And all of these issues
apply not just to when users click the main navigation tabs at the top
of the screen, but also GTRR buttons throughout the layout.
So if the database is going to emulate a single-window system as well
as give users the ability to see windows side by side, it needs to
know the visibility status of other windows. That's because it should
behave differently if the user can see a window in the background vs.
if he can't. If he can, leave it where it is and just select it. If
he can't, make it visible either in the location of the current window
(simple click) or offset from the location of the current window
(shift-click). But Ursus' solution does the trick by storing the
state of the windows in variables.
Does that make sense? It's not exactly an easy issue to describe on
paper and I appreciate your suggestions.
Best,
-J.
Thanks for spending time on this. You're right that the visibility
status of a window doesn't matter -- except when it does.
Unfortunately, explaining it in writing is a little cumbersome, so I
apologize in advance for that.
Here's the setup: Three windows named Customers, Vendors and
Prospects. A simple click on one of the tabs hides the current window
and makes the destination window visible in the same location and with
the same dimensions as the current window. For example, say I'm in
Customers; if I click the Vendors tab, FM will show the Vendors window
using the location and dimensions of Customers, then hide Customers.
This scenario might be called "single-window emulation." The
visibility status of any given window doesn't matter; the script works
by using the current window's name and the destination window's name.
The important thing to note in this process is that, in order to
emulate a single-window, the destination window has to be set to the
same location and dimensions as the current window. If it didn't do
that, windows would become visible wherever they were last located,
which would be pretty strange behavior from a user perspective.
Second scenario: A shift-click on one of the tabs indicates that the
user wants to see the destination table in a different window.
"Different" means different from the user's perspective, since in
actuality the tables are always being displayed in a different
window. So we might say that shift-clicking means "let me see two
windows simultaneously" (or three, or six, or however many tables the
user wants to open at the same time). So when the user shift-clicks a
tab, FM makes the destination window visible, but this time offsets it
by, say, 25 pixels, and instead of hiding the current window, leaves
it visible. For example, I'm in Customers; I shift-click the Vendors
tab. The script will display the Vendors window next to the Customers
window -- that is, make it visible in a location offset from
Customers. So far so good; the visibility status of any given window
still doesn't matter.
But then, in order to go back to Customers, the user reflexively
clicks the Customers tab in the Vendors window, even though he could
just click the Customers window with his mouse or hit Command-tilde or
whatever. There are multiple ways to get back to the Customers
window, and the one he chooses is to click the Customers tab. If the
database knew that the Customers window was visible, it would just
select Customers. But since it doesn't know that, it does what it
always does when you click a tab, which is to make the destination
window visible in the same location as the current window.
In other words, instead of just selecting the Customers window, it
yanks it out of its place and puts it where the Vendors window was
located, then hides Vendors. From a user's perspective, this is
pretty disconcerting. The database should've known that he was
looking at two windows (that is, that he had two windows visible) and
adjusted its behavior by simply selecting the Customers window instead
of moving it.
This problem is similar if he's looking at two tables -- Vendors in
the foreground and Customers in the background -- and shift-clicks the
Customers tab. Now instead of just selecting the Customers window, it
yanks it out of place and offsets it from the Vendors window. Again,
from a user's perspective disconcerting. And all of these issues
apply not just to when users click the main navigation tabs at the top
of the screen, but also GTRR buttons throughout the layout.
So if the database is going to emulate a single-window system as well
as give users the ability to see windows side by side, it needs to
know the visibility status of other windows. That's because it should
behave differently if the user can see a window in the background vs.
if he can't. If he can, leave it where it is and just select it. If
he can't, make it visible either in the location of the current window
(simple click) or offset from the location of the current window
(shift-click). But Ursus' solution does the trick by storing the
state of the windows in variables.
Does that make sense? It's not exactly an easy issue to describe on
paper and I appreciate your suggestions.
Best,
-J.
Ursus
Apr 27, 2012, 4:22:45 AM4/27/12
to
"jahn" <jahnbi...@yahoo.com> schreef in bericht
news:a637b7ee-9a26-4843...@p6g2000yqi.googlegroups.com...
You have three windows
$$Win1 = "NameOfWindow1_State" ("Costs_hidden)
$$Win2
$$Win3
You will have to do some parsing but maintaining only 3 variables is easier
then 6.
Ursus
David Stone
Apr 27, 2012, 8:38:06 AM4/27/12
to
In article
<a637b7ee-9a26-4843...@p6g2000yqi.googlegroups.com>,
Did you know you can specify precise size and location of the windows
via the same script commands? Just a thought - but combined with the
other suggestion of setting globals for each window state (which your
script can obviously toggle as it executes), you should be good!
<a637b7ee-9a26-4843...@p6g2000yqi.googlegroups.com>,
via the same script commands? Just a thought - but combined with the
other suggestion of setting globals for each window state (which your
script can obviously toggle as it executes), you should be good!
jahn
Apr 28, 2012, 12:50:12 AM4/28/12
to
Hi, David -
Yes, that's how I decided to go -- setting variables like $$top, $
$left, etc. and using them wherever a script step allows for size and
location specs. Then I created several subscripts -- Get Window
Coordinates, Set Window to Visible, Set Window to Hidden, etc., and
call them when I need to, so if anything changes in the design, I only
have to change it in one place. It's surprisingly clean: no blinky
behavior; no need to save tab control states each time the user leaves
a layout or restore them when he returns. Thanks for your
suggestions. I'm pretty happy with the results.
-J.
Yes, that's how I decided to go -- setting variables like $$top, $
$left, etc. and using them wherever a script step allows for size and
location specs. Then I created several subscripts -- Get Window
Coordinates, Set Window to Visible, Set Window to Hidden, etc., and
call them when I need to, so if anything changes in the design, I only
have to change it in one place. It's surprisingly clean: no blinky
behavior; no need to save tab control states each time the user leaves
a layout or restore them when he returns. Thanks for your
suggestions. I'm pretty happy with the results.
-J.
jahn
Apr 28, 2012, 12:53:31 AM4/28/12
to
Hi, Ursus -
Yes, that's basically how I decide to go: $$stateCustomers, $
$stateVendors, $$stateProspects. Then I use 0 for hidden and 1 for
visible and it's about as easy as it gets. Clean, simple,
straightforward. It's nice when something that looked like it was
going to be a headache turns out to be a piece of cake. Thanks for
the tip. I'm sure I would've tied myself in knots trying to do it
some other way.
-J.
Yes, that's basically how I decide to go: $$stateCustomers, $
$stateVendors, $$stateProspects. Then I use 0 for hidden and 1 for
visible and it's about as easy as it gets. Clean, simple,
straightforward. It's nice when something that looked like it was
going to be a headache turns out to be a piece of cake. Thanks for
the tip. I'm sure I would've tied myself in knots trying to do it
some other way.
-J.
jahn
Apr 28, 2012, 12:41:56 AM4/28/12
to
Hi, Ursus -
Yes, that's what I did. One variable for each window -- $
$stateCustomers, $$stateVendors, $$stateProspects -- with a 0 or 1
assigned depending on whether it's hidden or visible. It turns out to
be really straightforward and seamless. It's great when that
happens. Thanks for the tip.
-J.
Yes, that's what I did. One variable for each window -- $
$stateCustomers, $$stateVendors, $$stateProspects -- with a 0 or 1
assigned depending on whether it's hidden or visible. It turns out to
be really straightforward and seamless. It's great when that
happens. Thanks for the tip.
-J.
0 new messages