locked
DeviceInfo.LogicalNames is empty RRS feed

  • Question

  • I have gotten a citizen CT-S851 working working on my machine using their .NET for POS. I have tested this using a test app they provide (http://www.citizen-systems.co.jp/english/support/download/printer/driver/pos_dot_net/data_dotnet/SamplePro.exe), which seems to work just fine.

    For the life of me I cant get this thing to work in my winforms C# application. For starters, I cant get a proper listing of the POS printers. The sample app from citizen can list numerous POS printers - the MS Simulator, a number of other citizen models, and most importantly the logical name of my CT-S851 (XYZ), as shown below:

    When i try to do something similar my app, I dont get the logical name of my printer - I get the ServiceObjectName get something like below:

    I should point out, I have used reflector to look into the sample app, and my code in this area is pretty close to the sample app. The code that is generating this display name is:

            private string GetDeviceDisplayName(ref DeviceInfo device)
            {
                string serviceObjectName = this.CombineNames(device.LogicalNames);
                if (serviceObjectName.Length == 0)
                {
                    serviceObjectName = device.ServiceObjectName;
                    if (serviceObjectName.Length == 0)
                    {
                        serviceObjectName = device.Description;
                    }
                }
                return serviceObjectName;
            }
    

    In my app, the device.LogicalNames is always empty.

    What could be causing this? What effects the population of the device.LogicalNames property?

    Thanks.

    Saturday, December 10, 2011 12:57 AM

All replies

  • Bit more information:

    Interestingly, the Microsoft POS Tester does not show my citizen POS Printer, even though the citizen .NET test utility does:

    Saturday, December 10, 2011 2:11 AM
  • It is a little confusing that they call their app .NET for POS. Does it mean it is writen in .NET or does it mean it supports POS for .NET? If the SDK test app isn't see the device, it means the service object or OPOS driver is not installed.

    based on your other post you got something to install. The question is why doesn't the SDK app not work.

     

    -Sean


    www.sjjmicro.com / www.seanliming.com / www.annabooks.com, Book Author - Pro Guide to WES 7, XP Embedded Advanced, Pro Guide to POS for .NET
    Saturday, December 10, 2011 5:03 AM
    Answerer
  • It is a little confusing that they call their app .NET for POS. Does it mean it is writen in .NET or does it mean it supports POS for .NET? If the SDK test app isn't see the device, it means the service object or OPOS driver is not installed.

    I would ask the manufacture about a service object and POS for .NET support.

     

    -Sean


    www.sjjmicro.com / www.seanliming.com / www.annabooks.com, Book Author - Pro Guide to WES 7, XP Embedded Advanced, Pro Guide to POS for .NET
    Thanks. I have installed the .NET drivers for this printer. Having had a look at their app with .NET Reflector, the app is both written in .NET, and uses POS for .NET (It has Microsoft.PointOfService as one of the references).
    Saturday, December 10, 2011 5:11 AM
  • After an extremely frustrating day, I have made two discoveries while playing with the source code of the pos sample app (provided by microsoft) that could lead me to some answers.

    Firstly, it is set to run as "any CPU". As my machine is 64 bit, it would run as 64 bit. From what I have read, POS for .NET does not play nice in 64 bit, so I switched it back to x86, and it started seeing my POS printer correctly. A bit odd that the sample app should be built as "Any CPU", when the underlying technology (POS for .NET) does not work when run as 64 bit.

    While this explained why the MS test app was not seeing my printer, it did not explain why my real app was not working (I compile it as x86 only).

    The next thing I noticed was that it (the MS test app) compiles as "Debug". I changed this to release, and it started behaving as my real app does (not seeing logical names). It seems the Release/Debug thing makes a difference. I'll need to do some more tests to ensure this is not a problem after deployment (I cant deploy this as debug...).

    Saturday, December 10, 2011 12:33 PM
  • Still havnt got it working yet.

    If I create a brand new winforms application, set its properties similar to my main app (winforms, .net v2.0), and set it to build to Debug/x86, this can find the post printers along with their logical names. If I change the ubild from Debug to Release, it still finds the printers, but not the logical names of the printers. This is as expected from my previous findings (above).

    But when I make these same changes in my main app (change to debug mainly), I still dont get any logical names.

    And in anycase, I really need it working when solution configuration is "Release", as that is what I release my software as.

    Am I missing something here? Is there a good reason why I'm getting this odd behaviour?

    Saturday, December 10, 2011 9:46 PM
  • Enable PosForNet logging (POSfor.NET\Logging\Enabled in Registry) and then see the log.

    Monday, December 12, 2011 9:22 AM
  • Enable PosForNet logging (POSfor.NET\Logging\Enabled in Registry) and then see the log.

    Thanks, but I've kind of given up. I'm now just using the windows driver, pushing text directly to it using the PrintDocument class.

    I have lost a little bit of functionality, but I've gained my sanity.

    Monday, December 12, 2011 9:26 AM