首先java怎样使窗口隐藏，java怎样使窗口隐藏呢?你在SetVisible(false)
之后是不是有其他操作将该window给destroy了.
或者在SetVisible(true)只有又调用了SetVisible(false). 断点跟踪.
还有一种可能就是SetVisible(true)这句根本没被执行.
固然在JAVA语言中要实现类的躲藏非常简朴，只需要通过三个枢纽字即可以完成。但是在大部门情况下，让JAVA程序员感到迷惑的是，在什么时候该把什么类躲藏。确实，在JAVA开发语言平台中，对于什么类需要躲藏，什么类不需要躲藏，往往没有很严格的要求。为此程序开发职员需要根据自己的工作经验来进行判定。而即使有一定程序开发经验的员工，也不一定能够在这个题目上给出很好的谜底。公说公有理，婆说婆有理，为此很难有一个同一的尺度。笔者下面几个建议，也是对自己这几年来JAVA开发工作的总结。但愿这些建议能够匡助大家解惑。
1、不同模块之间的类要相互躲藏。现在不少应用系统，为了进步开发效率，都提出了模块化的设计理念。如最近比较流行的ERP系统，假如按模块来进行设计的话，则在开发时不同的职员可以负责各自的模块，而互不干涉。在ERP系统出售的时候，也可以按模块来进行出售，由于各个模块的功能是相对独立的。当然这只是从治理层面来说模块化设计的重要性，不外这不是我们今天要谈论内容的重点。今天要谈的是，假如应用系统按模块化来进行设计，那么不同模块之间的内如何实现躲藏呢?实在很简朴。如供给商基本信息维护、供给商进货单、应付帐款分属于三个不同的模块，分别为采购治理、库存治理与应收应付治理。现在在设计应收应付这个模块时其中有一个天生应付帐款的类，其需要用到采购治理模块中供给商的信息(付款前提等等)、仓库治理模块中的供给商进货单据(产品编号、数目、到货日期等等)，然后才能够天生正确的应付帐款。那么在应用程序设计的时候该如何实现呢?是在那个应付帐款功课对应的类中直接从数据库中去查询这些信息吗，又或者去修改采购模块中对应的类来实现?这固然都可以达到预定的目的，但是都不是上上之策。个人以为，最好的方法就是程序开发职员先设计一个类(如Vender类)，这个类会返回供给商编号、付款前提等信息。然后应付帐款功课中的类就直接调用这个类获取需要的信息。一方面可能良多地方都需要用到这些信息，假如每次需要的时候都利用SQL代码来获取这些信息的话，那么代码量也会很大。相反直接调用类来实现这些信息反而更加的方面。另一方面，这个Vender类对于其他类是躲藏的。也就是说，其他类只能够通过预定义的接口向这个类传递参数并直接引用其返回的结果，而不能够修改类内部的元素。如斯即使其他有十几个类或者应用程序需要调用这个类的时候，其只要输入的参数相同，则其返回的结果也就相同。那么其他类在引用返回结果的时候，就不用担心不兼容了。所以，应用程序的模块化设计促使JAVA程序要实现类与类之间的躲藏;同时JAVA类相互之间躲藏的特性也利便了应用程序的模块化设计。
2、数据类型类与其他类之间需要实现躲藏。在任何一个应用程序开发过程中，都需要根据企业的需要设计一些比较有针对性的数据类型。由于光靠应用程序所提供的那些数据类型往往不能够知足程序开发职员的需要。如需要设计一些数组、记实等等数据类型。但是在设计这些数据类型的时候，程序职员就需要了一个挫折。如现在在开发ERP系统的过程中，多个模块(每个模块由不同的程序员负责)都需要用到统一个记实数据类型。那么是每个程序员都设计一个记实类型的数据类型，仍是共用统一个数据类型呢?假如各管各的，就需要建立多个记实类型的数据类型，治理起来比较麻烦，对后续进级也会碰到障碍。而假如大家共用一个记实类型的数据类型，大家又担心其他程序职员不小心修改了这个数据类型而给他们造成了麻烦。这之间岂非就没有和平的共存方式了呢?实在，在应用程序开发的过程中可以以为的将应用程序开人职员分为数据类型创者者与业务逻辑开发者。然后数据类型开发者可以根据其他开发职员的需要创建一些定义数据类型的类，这些类的话对于其他程序开发职员开发的类是躲藏的。也就是说，其他类不能够对这个数据类型进行修改。那么即可以进步这些数据类型的利用率，而且也可以保证其他类可以以固定的格局引用这些类。
3、业务层与表示层之间的类要相互躲藏。利用过J2EE开发平台的人肯定知道，在开发应用程序的时候，业务逻辑层与表示层之间是相互独立的。业务逻辑层主要实现一些负责的运算，如物料需求计划运算。而表示层的话只负责一些详细的显示。如通过浏览器客户端来显示结果仍是通过软件窗口来显示运算结果。固然客户端所采用的方式不同，但是其内部的运算是相同的。此时最好把实现业务逻辑层的类与实现表示层的类相互躲藏起来。由于在实际开发过程中，他们往往是由不同的程序开发职员完成的。为了避免不同程序开发职员之间的相互干扰，避免表示层的开发职员无意中修改了业务逻辑层的JAVA类，就必需要把业务逻辑层的类躲藏起来。也就是说，表示层开发职员只需要知道业务逻辑层的类需要哪些参数、能够以什么样的形式返回结果即可。然后表示层的类在调用业务逻辑层中的类的时候，只需要按照要求输入参数、按照规则获取结果即可，而不需要关注其业务逻辑层类内部的实现机制，从而减轻了表示层开发职员的工作量。同时也避免了业务层开发职员对这个类进行修改，从而其他的应用程序开发职员可以以统一种方式来引用这些类。
4、假如某个业务逻辑还不怎么完善时，要执行躲藏。在应用程序开发的过程中，可能某些业务逻辑暂时没有很好的解决方案，但是需要的参数或者返回的结果是确定的。此时可以把这个业务逻辑建立一个的类，并对其他类进行躲藏。如斯的话，当泛起更好的解决方案之后，就可以直接更改这个类中的业务逻辑。因为类中成员对于其他程序职员是躲藏的，为此对类中的处理机制进行更改并不会影响到其他职员开发的应用程序。他们只关心你能够在最短时间内获得正确的结果。为此在碰到这种情况时，最好把类与其他的类执行躲藏。
可见，哪些类需要相互躲藏可能判定起来比较复杂。但是有一个普遍合用的原则，就是假如一个类有不同的程序职员需要引用。如用户A设计了一个统计应收帐款余额的类，用户B与C，包括用户A都需要调用这个类。那么这个类就最好进行躲藏。防止其他类在调用这个类的时候，不小心修改了其内部的实现方式。这会对其他用户调用这个类产生不利影响。
二、实现JAVA类躲藏的三个枢纽字
之所有要实现JAVA类躲藏，主要是让任何程序开发职员都无法触及他们不应该初期的部门(如业务逻辑或者数据类型的内部操纵)。固然项目治理员可能在程序开发过程中多次告诫团队成员不要直接操纵其他开发职员所设计类中的成员。但是假如缺乏一定的控制手段，这些事情往往会在有意无意中发生。为此需要采取一些强制的手段来防止这些情况的发生。而且这些事现方式必需简朴，不能够太过于复杂。在JAVA语言平台中，就提供了Public、private、protected三个枢纽字来实现对类的躲藏与控制。
这些枢纽字决定了类或者类中的成员是否对其他类是躲藏的，能否被其他类进行操纵与修改。如public枢纽字表示紧随其后的元素对任何人都是可用的，可以被任何人所修改。而枢纽字Private则表示除了类创建者和这个类型的内部方法之外的任何人都不能够进行访问。而枢纽Protected的作用跟Private类似，只是其是作用在继续中的。
可见在JAVA程序开发中，要实现类的躲藏是很简朴的，也是JAVA程序员必需要把握的一项基本功。而其难度就在于在适当的时候实现类和类中成员的躲藏。这就要程序员在程序开发过程中好好琢磨了。上面提到的一些建议可供大家做参考。
相关推荐：

     SpringBoot以标准Java 应用的形式，来启动了一个Web服务，而将容器的存在，隐藏在一个配置文件中，使用起来很方便。而Tomcat 就是Spring Boot内置的容器之一。这次我们来看在SpringBoot中，Tomcat中怎样被集成进来提供服务的。

      近一两年， SpringBoot 由于其减少了大量原本繁琐的 Spring 配置，以及基于 Boot 的 SpringCloud 的推广，越来越多的应用开始使用 SpringBoot进行开发。

      而 SpringBoot 以标准Java 应用的形式，来启动了一个 Web 服务，而将容器的存在，隐藏在一个配置文件中，使用起来很方便。而 Tomcat 就是 Spring Boot 内置的容器之一。

      这次我们来看在 SpringBoot 中， Tomcat 中怎样被集成进来提供服务的。

      前面的文章写过关于 Tomcat 的 Digester 组件解析 配置文件 server.xml， 根据配置信息生成 Tomcat 实例。

      在 Spring Boot 中，实现也基本类似。 区别在于配置信息大部分是默认的，另外一些用户特定设置的，通过在 application.properties 之类的 Boot 配置文件里，读出来解析并设置到 Tomcat 的各个组件上。

另外一个区别是， Spring Boot 使用的是 Embedded Tomcat 。



要分析这个问题，该从哪看起呢?

Boot 在启动的时候，很清楚的告诉我们这样一条信息

s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat initialized with port
		
可以匹配到这一行 log 的, 是 container 的init 方法



前面一些细节类的内容先不过多关注，进入眼里的， 一定是这个

this.tomcat.start(); 
这里这个 tomcat ，就是 Embedded Tomcat类的实例。

这里 start 的操作，是将容器启动起来



方法里的 getServer, getConnector 这些， 熟悉 Tomcat 的朋友都了解，Tomcat 内部有以下几个主要的组件:

Egine
	
Host
	
Context
	
Wrapper
	
Connector
      前四个是容器从上到下的组件，是一个包含的关系。而光有这些还不足以让我们访问到部署的应用，此时容器连接外界的组件 Connector 就显的必不可少了。

       而且，真正到了start 这一步的时候，容器的组件配置都已经完成了，只是要启动以提供服务。 配置的这些读取，都是在 initial 阶段之前，已经完成。

      下图是初始化阶段读取配置时的一些代码， 没有特别的地方，设置 BaseDir， 解析配置设置各个组件。



此外，在Spring Boot 应用启动时,会有这样几条日志输出。



      我们知道，Spring MVC 是通过 DispatcherServlet 来分发处理请求，在 Spring Boot 出现之前，都是需要在web.xml里配置，来实现请求的拦截。

      而在Servlet 3.0 之后，规则中新增了Dynamic Servlet、Dynamic Filter这些概念, 可以在运行时动态注册组件到 Context 中。



     所以我们观察到的 Context 仅仅是一个空的应用，然后再通过动态添加Servlet、 Filter 等内容进去。

     除了以 Jar 的形式直接执行 Main 方法外， Spring Boot 还支持将 Boot 应用打包成 War 文件，部署到标准和容器中，不使用 Embedded 容器。

     相比执行 Main 方法来启动 Spring Boot 应用，以 Web 应用提供时， Boot 的能力是如何提供的呢?

来看下面这张图，Jar文件的META-INF中services中包含一个SCI的声明。



这就是Spring Boot 在标准Web容器中能生效的秘密。

SCI是做什么的呢?

      容器启动时会依次处理每个 ServletContainerInitializer 的HandlesTypes注解，然后分别调用所有ServletContainerInitializer对象的onStartup方法，并将处理HandlesTypes注解得到的类数组，传递给ServletContainerInitializer的onStartup方法。

在configure阶段，我们将 Boot 打包成 war 时提供的Initalizer，并将其 run 起来。

此时处理 dispatcherServlet 这些，和 以Main方法启动执行没什么区别。

 所以，当我们看到 Boot 应用能够以如此少的配置便利的作为 Web 应用执行时，要清楚的认识到，背后的 Embedded 容器 还是做了不少工作，同时也是和各种新的 J2EE规范有关。 而最重要的是，无论怎么变化，本质上还是那样，做为一个标准的 Context 在使用，区别只在于是通过解析静态文件进行配置，还是通过动态添加进行配置。

 

 

    

                    

                    

                    
                    
                    
来源 | 公众号 | Tomcat那些事儿
作者 | 侯树成 
近一两年， SpringBoot 由于其减少了大量原本繁琐的 Spring 配置，以及基于 Boot 的 SpringCloud 的推广，越来越多的应用开始使用 SpringBoot进行开发。
而 SpringBoot 以标准Java 应用的形式，来启动了一个 Web 服务，而将容器的存在，隐藏在一个配置文件中，使用起来很方便。而 Tomcat 就是 Spring Boot 内置的容器之一。
这次我们来看在 SpringBoot 中， Tomcat 中怎样被集成进来提供服务的。
前面的文章写过关于 Tomcat 的 Digester 组件解析 配置文件 server.xml， 根据配置信息生成 Tomcat 实例。(Tomcat配置文件解析与Digester)
 在 Spring Boot 中，实现也基本类似。 区别在于配置信息大部分是默认的，另外一些用户特定设置的，通过在 application.properties 之类的 Boot 配置文件里，读出来解析并设置到 Tomcat 的各个组件上。
另外一个区别是， Spring Boot 使用的是 Embedded Tomcat 。这个我们在前面的文章里也曾简单介绍过 (Embedded Tomcat，朋友，要不要试试)
 当然，上面这两点，是整个 Boot 项目中使用到 Tomcat 的基本原理，但具体对于 Embedded Tomcat 的使用，Boot 里和 Maven 插件的使用还是有一些区别的。
这是 Boot 使用的三个embedded 容器，默认启动的是 Tomcat。
要分析这个问题，该从哪看起呢？
Boot 在启动的时候，很清楚的告诉我们这样一条信息
s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat initialized with port 
我们看到的这一条是logback输出的信息。前面是缩略形式写的包名，最主要的是这个Container，跳转到类里看一眼。
可以匹配到这一行 log 的, 是 container 的init 方法
前面一些细节类的内容先不过多关注，进入眼里的， 一定是这个
this.tomcat.start();
这里这个 tomcat ，就是 Embedded Tomcat类的实例。
这里 start 的操作，是将 容器启动起来
方法里的 getServer, getConnector 这些， 熟悉 Tomcat 的朋友都了解，Tomcat 内部有以下几个主要的组件:

Egine
Host
Context
Wrapper
Connector

前四个是容器从上到下的组件，是一个包含的关系。而光有这些还不足以让我们访问到部署的应用，此时容器连接外界的组件 Connector 就显的必不可少了。
而且，真正到了start 这一步的时候，容器的组件配置都已经完成了，只是要启动以提供服务。 配置的这些读取，都是在 initial 阶段之前，已经完成。
下图是初始化阶段读取配置时的一些代码， 没有特别的地方，设置 BaseDir， 解析配置设置各个组件。
此外，在Spring Boot 应用启动时,会有这样几条日志输出。
我们知道，Spring MVC 是通过 DispatcherServlet 来分发处理请求，在 Spring Boot 出现之前，都是需要在web.xml里配置，来实现请求的拦截。
而在Servlet 3.0 之后，规则中新增了Dynamic Servlet、Dynamic Filter这些概念, 可以在运行时动态注册组件到 Context 中。
所以我们观察到的 Context 仅仅是一个空的应用，然后再通过动态添加Servlet、 Filter 等内容进去。
除了以 Jar 的形式直接执行 Main 方法外， Spring Boot 还支持将 Boot 应用打包成 War 文件，部署到标准和容器中，不使用 Embedded 容器。
相比执行 Main 方法来启动 Spring Boot  应用，以 Web 应用提供时， Boot 的能力是如何提供的呢？
来看下面这张图，Jar文件的META-INF中services中包含一个SCI的声明。
这就是Spring Boot 在标准Web容器中能生效的秘密。 
SCI是做什么的呢？
容器启动时会依次处理每个 ServletContainerInitializer 的HandlesTypes注解，然后分别调用所有ServletContainerInitializer对象的onStartup方法，并将处理HandlesTypes注解得到的类数组，传递给ServletContainerInitializer的onStartup方法。
在configure阶段，我们将 Boot 打包成 war 时提供的Initalizer，并将其 run 起来。
此时处理 dispatcherServlet 这些，和 以Main方法启动执行没什么区别。
所以，当我们看到 Boot 应用能够以如此少的配置便利的作为 Web 应用执行时，要清楚的认识到，背后的 Embedded 容器 还是做了不少工作，同时也是和各种新的 J2EE规范有关。 而最重要的是，无论怎么变化，本质上还是那样，做为一个标准的 Context 在使用，区别只在于是通过解析静态文件进行配置，还是通过动态添加进行配置。

关注『 Tomcat那些事儿  』 ，发现更多精彩文章！
本次送书
新的一年，第一次送书活动！
本公众号文末不定期赠书！
从今天起，每天早晨打开《Java后端技术》公众号，不但可以收获技术，说不定还可以顺便带走一本书哦！
送书规则
1、本次活动还是在评论区随机抽取一名幸运吃瓜群众！
2、截止日期：2018年02月27日23时00分，幸运的小伙伴名单评论区留言会置顶，获奖的小伙伴请在一个工作日内在公众号界面联系我，发送手机号、姓名、收货地址，逾期则认为放弃处理；
3、注意啦：经常关注Java后端技术公众号留言点赞的小伙伴会自带红蓝buff加成哦！

两本书中一本从留言区抽取，一本从“抽奖助手”中抽！

点击图片查看更多推荐内容
↓↓↓
年后返程的程序员:带不走的，是家里的爱！
Web 和 Chrome 开发者之间的那些事！
一步步带你了解前后端分离利器之JWT

  

MFC 怎么样可以让应用窗口随意拖动，即在隐藏了对话框的TitleBar之后，还能随意拖动窗口


方法一：
重载WM_NCHITTEST，然后将OnNcHitTest里内容修改为：
 UINT   nHitTest   =   CDialog::OnNcHitTest(point);   
 if   ((nHitTest   ==   HTCLIENT)   &&   (::GetAsyncKeyState   (MK_LBUTTON)   <   0))   
  nHitTest   =   HTCAPTION;   
 return   nHitTest;  


方法二：
重载WM_LBUTTONDOWN，在OnLButtonDown中添加：
 PostMessage(WM_NCLBUTTONDOWN,HTCAPTION,MAKELPARAM(point.x,   point.y));